views:

510

answers:

1

Project Background: I am setting up a small farm where the Intranet is its own application. Following the Least Priveleged Account setup principle, I have Domain User accounts created for each process/app. pool. The service authentication works great over Kerberos.

One of the projects needs to have another web application (separate from the Intranet) exposed to clients through the Internet. In order to keep the AD structure separate, we decided to go with ADAM. The app. pool account is separate and also uses Kerberos. Following https://blogs.pointbridge.com/Blogs/morse_matt/Pages/Post.aspx?_ID=2, I extended my original application and configured it as an Extranet zone assigning an LDAPMembership provider as outlined in the article.

The dilema While the people picker works and allowes me to specify Collection Administrators, Site Owners, Members, etc. from both AD and ADAM data stores, I am not able to log my users in. I constantly get the user could not be authenticated error. And nicely enough, the LOG produces no errors related to Directory lookups. It seems that the ADAM data store is never hit.

My own idea, based on MS articles, is that because I do not use NTLM, the crawler never gets to the Extranet zone. Yet, how should I go about securing the application if we all know that Kerberos is superior to NTLM.

Any ideas would be very much appreciated.

Note: SPNs were properly set up, permissions were assigned as required, the ADAM users have disabled set to false, app. pool accounts are listed in the Readers role container inside ADAM

Thanks, Jack

A: 

One thing that you could check is the opening of network ports. I am assuming that your web server and LDAP server are on different network segments.

Idea is that LDAP port and SSL port are different. If the people picker uses the LDAP port and the login uses the SSL port, then this could explain why one works and the other does not, and why the calls are not reaching the LDAP server.

Shiraz Bhaiji