I am having an issue with authentication pop ups internally as well as externally for sharepoint published on ISA 2006. The configuration I have done is:
1. ISA 2006 in DMZ with single NIC as a member of same domain as sharepoint servers. 2. sharepoint farm with 2 SP servers published. 3. Web Listener Authentication configured as Basic with Windows (Active Directory). 4. Authentication delegation configured as NTLM authentication. 5. IIS website for sharepoint configured as "Integrated Windows Authetication" checked on both the SP servers. 6. This is seperate domain for sharepoint extranet. 7. There is a trust with corporate domain for corporate user access.
Issue:
1. Internal Users get pop up for authentication even if they are on sharepoint domain or corporate domain. 2. After login if they try to access published documents like word docs they are prompted for authentication again.
Is there a way to avoid autentication pop up for internal users?
Please help me identify the issue and resolve it. Appreciate your help.
We're having similar issues. Two ISA 2006 SP1 servers configured as an array and three MOSS servers configured as a farm. I've tried the suggestion to remove authentication from the web listener but it hasn't made any difference.
We are also seeing authentication prompts when users jump from one MOSS site to another on the same farm (all published by the same ISA array) and when they open pages that contain images from other sites. The funny thing is we have an ISA 2006 array (no service pack) where this works fine.
I have played around with Trusted Sites settings, etc but this has not made any difference. Plus all of our desktop estate can access these Sharepoint sites without any problems when they go via our old ISA 2006 array.
Thanks for replying, Jason. I'm not sure if SSO would satisfy our requirements because these are internal users accessing the MOSS sites via ISA so they want to be able top open the sites without any authentication prompts. Admittedly I'm fairly new to ISA but I wasn't aware that you could configure SSO when using HTTP authentication...
Our configuration consists of two rules for each site with one rule listening on an Internal address using HTTP Integrated authentication, and a second rule listening on an External IP address configured with Forms authentication.
What's really puzzling me is that this works fine on our old ISA array and as far as I can tell the rules are configured identically.
I've just had a play around with the authentication on the rule and I didn't realise that you could configure FBA with NTLM and it doesn't prompt. However, I do still seem to be having the same issue so I think I may need to go back and check my rule configuration...
Currently have 1 rule that handles both internal and external users. It uses KCD and SSL Client Certificate Auth on the listener. This is working just fine. However, internal users don't want to be prompted for a certificate anymore, so we need to create a new rule that listens only internally and changes the listener authentication to HTTP Integrated.
I copied the first rule, made the appropriate listener changes and users are getting prompted internally for username and password. No combination of credentials is letting us through. I've tried all authentication and delegation combinations (KCD, the 2 no delegation options, no authentication)... All no go.
I can, however, use the same rule and setup FBA and after putting in my credentials I can get right through. This would be using KCD as well.
I've ensured that require all users to authenticate is unchecked and it's not a IE Trusted Sites or IE Integrated Auth issue.
Yes, it's very frustrating and there doesn't seem to be any consistency to the way the authentication prompts behave either. My previous post about FBA with NTLM not prompting seems to be from an inconsistency on the array because I'm not sure that's how it should behave.
We have our MOSS sites listed in Trusted Sites and it does seem to alleviate some of the problems so that might be worth trying.
Also, have you tried removing authentication all together from your internal rule? In testing I managed to get that to work on the array in our lab but I'm not sure if that will alleviate our "SSO" issues when users jump from one site to another and when I tried implementing the same change in the LIVE environment it didn't work in the same way as the lab and I was prompted for a username and password.
Posts: 4663
Joined: 30.Jul.2002
From: United Kingdom
Status: offline
Maybe I am missing something here, but do you gain a lot of value by authenticating internal users at ISA? Surely it would be a lot more efficient to to use a No Authentication web listener combined with No delegation, but client can authenticate for internal users?
You then have two rules (or more) defined using split DNS:
sharepoint.domain.com interally points to No auth web listener using an internal IP
sharepoint.domain.com externally points to the FBA web listener using an external IP (or SSL cert auth if preferred)
If you have multiple rules that use each listener, you should then be able to enable SSO across the rules.
To keep a consistent protocol, I would also use HTTPS both internally and externally (and confuse users less). The cert on the internal No Auth web listener could be issued from an internal CA to save public certs cost.
If you want to eliminate Office auth prompts, you can then enable persistent cookies on the external FBA web listener.
You're absolutely right, there is no added value by using ISA internally and in fact it just adds an extra layer of complexity and impacts on performance in my opinion. However, using ISA internally is a mandatory requirement for our customer and we have agreed to meet that requirement so I need to make it work.
Having done some more testing I am beginning to see that "No Authentication" on the listener could well be the solution to this. We have some discrepancies between our Lab environment and the LIVE environment which may have been causing the odd behaviour I saw yesterday, so it's back to the drawing board today to try and get all the sites to working happily internally with "No Authentication" listeners.
Thanks for taking the time to reply, I really appreciate your help.
Posts: 4663
Joined: 30.Jul.2002
From: United Kingdom
Status: offline
quote:
ORIGINAL: bluwe
You're absolutely right, there is no added value by using ISA internally and in fact it just adds an extra layer of complexity and impacts on performance in my opinion. However, using ISA internally is a mandatory requirement for our customer and we have agreed to meet that requirement so I need to make it work.
No problem
Note that I didn't say "dont use ISA for internal users", I said "dont authenticate internal users with ISA" a subtle difference ISA can add a lot of value, even for internal access; i'm just not sure pre-auth with ISA is necessary in that scenario.
Keep us posted on your findings...
Cheers
JJ
< Message edited by Jason Jones -- 10.Sep.2009 6:00:36 AM >
We're using ISA as the load balancer for the Web FE farm.
I tried No Authentication as well, along with no delegation (but client can authenticate directly) but I get an immediate "403 Forbidden. The server denied the specified Uniform Resource Locator (URL). Contact the server administrator. (12202)"
< Message edited by AnthonyP -- 10.Sep.2009 8:48:46 AM >
Posts: 4663
Joined: 30.Jul.2002
From: United Kingdom
Status: offline
quote:
ORIGINAL: AnthonyP
We're using ISA as the load balancer for the Web FE farm.
I tried No Authentication as well, along with no delegation (but client can authenticate directly) but I get an immediate "403 Forbidden. The server denied the specified Uniform Resource Locator (URL). Contact the server administrator. (12202)"
Did you change from All Authenitcated Users to All Users?
OK, time for an update and I have good and bad news....
The Good:
Removing authentication from the rules for our MOSS sites has completely resolved the authentication prompts issue....woohoo!!
The Bad:
Users are now reporting performance problems when accessing the MOSS sites...doh!!
My immediate reaction was to blame MOSS, however, when accessing the sites through the old array it is lightning fast. One subtle difference is that the old array is in the same domain as the MOSS servers so I am starting to think the performance problems are authentication related. Has anyone got any ideas? I think this problems is going to send me mental!
Hallo, Jason Jones wrote: "Auth prompts in Office apps can be cured by using persistant cookies. "
We have the same problem withthe behavior of MS-office apps.
Situation: 1. SSO for internet users for OWA and Sharepoint internal site. Works good. 2. When a user try to open a MS-office doc like .xls or .doc he gets the basic authentication prompt.
My questions: 1. How persistant cookies help? 2. What's the risk? 3. Is there a drawback?
< Message edited by guyhorn -- 7.Oct.2009 6:05:29 AM >