Re: ActiveDirectoryMembershipProvider woes



The internal calls to the HttpContext certainly make that less attractive. I'm a little sad that something like a provider which should have very low coupling to the core server components would do such nasty stuff, but so it goes. I actually don't really like the membership provider very much as it is as I don't like how it conflates authentication with provisioning. I think they should be separate concerns. But, that ship has sailed.

Win auth essentially means you are offloading to IIS, so it depends on the IIS auth settings. The only setting that allows for "SSO" behavior is integrated auth. Basic and Digest require the user to supply credentials. Integrated will challenge for creds if SSO can't be made to work, so that's where the fiddling with IE settings may come into play. From the ASP.NET perspective, it treats this all the same since it just gets an NT login token from IIS and converts that into an IPrincipal object (based on WindowsPrincipal), so you just enable Windows auth in web.config and the rest is basically up to IIS.

The referral happens when you search for an object in one naming context and it is not in that context, but the server thinks it is in a different context. This usually only happens when you search in domain1 and the object in question is in domain2. Thus, if you are really specifying the correct domain where the user is, there should be no referral.

This is why I keep asking about that. If you have a case where you need to authenticate users from both domains, then you'd need to be able to search both. As I said, the GC would be the best way to accomplish that since it searches the whole forest simultaneously. You basically don't get referrals. However, I don't know if ADMP can be configured to do that. The fact that it needs to do a search at all in order to authenticate the user is kind of dumb but that's what it does.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
"Thomas" <replyingroup@xxxxxxxxxxxx> wrote in message news:er$u0tAAKHA.3556@xxxxxxxxxxxxxxxxxxxxxxx
RE: Reverse Engineering the ADMP

Heh, that is the road I was going down until I discovered calls to internal methods off the HttpContext object. I'm a daring guy but I'm not willing to add a custom version of that particular object. It might still be possible but there are *a lot* of internal calls in the ADMP. I was up to a 1/2 dozen internal classes when I discovered the internal method calls of HttpContext.

RE: Expandibility

Yeah, I suppose it would lower their test footprint but it is damn annoying especially, when I think that one line of code (setting the ReferralChaseOptions on the DirectorySearcher) would solve the problem. :).

RE: Referral and domain

I fairly sure that I'm connecting to the right domain. I can do a Run As with the command prompt, enter the same credentials and get in. So I know the credentials at least are valid. Wouldn't narrowing the conn string down to the exact OU and server eliminate the possibility of an incorrect server? Is there an ldp search that would resolve the question?

RE: Win Auth

I think we're talking about two different forms of Win Auth. If I set the authentication in my config file to "Windows", does that mean it offloads the authentication to IIS which then offloads to the domain and thus uses whatever settings you have on the site (basic, domain, integrated etc)? If that is the case, then perhaps I'm overlooking a configuration that would do the trick. I'll have to do some more experiments.

RE: Exact domain and OU

Looking past the specific domain name, the DN would be akin:
CN=VendorUser,OU=VendorUsers,OU=IT,OU=SysAccounts,OU=Foo,DC=CO,DC=Foo,DC=com

This particular company has two domains. Their AD in a folder like structure looks like:

co.foo.com
/companyA
/foo
/spiffyOU1
...
/spiffyOUn
/SysAccounts
/subspiffyOU1
...
/subspiffyOUn
/IT
/subspiffyOU1
...
/subspiffyOUn
/VendorUsers
VendorUser

That said, they have set the UPN of VendorUser to VendorUser@xxxxxxx (as opposed to VendorUser@xxxxxxxxxx).

One of the domains is in midwest and one is in CA. We (the vendor) are connecting directly to the one in the midwest where the AD is managed. (The CA office is a satellite office).


Thomas


.



Relevant Pages

  • Re: OWA User Connectivity Problem
    ... I have Forms Based Auth turned off. ... the exact same settings as my business domain and still doesn't work. ... > exchange dir in IIS... ...
    (microsoft.public.exchange.connectivity)
  • Getting SPNEGO HTTP headers to a CGI?
    ... The AppServer may be ... Basically i would need to put the HTTP auth headers into the CGI ... environment somehow but didn't find any IIS docs about it. ...
    (microsoft.public.inetserver.iis.security)
  • Re: Authentication Redirect to login doesnt work
    ... If you are using windows/basic auth in IIS - IIS will do the authentication ... you set IIS to do no authentication - and do it yourself ... windows integrated for windows NT auth. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • W2k3 IIS6 Basic auth over domain
    ... auth box in settings and selected domain and realm but when i try to access ... Furthermore I've tried NOT to specify domain and realm (just checked the ... and again specefying username inte the DOMAIN\USERNAME ...
    (microsoft.public.inetserver.iis.security)
  • support: on / off sync issues
    ... whenever I make a change in the IIS console and or restart the IIS ... all the phones switch their settings from their usual sync ... cause the phones to set themselves to "manually sync". ... defaultwebsite - intergrated windows auth + basic auth ...
    (microsoft.public.pocketpc)