How to solve problems with the ActiveDirectoryMembershipProvider and similar ldap integrations
The basics is already handled in the EPiServer SDK about membershipprovider. But what do you do when that doesn’t work? Here are some ideas and tools how to get that integration up and running when the night is getting darker and the coffee is running out…
Basic setup of ActiveDirectoryMembershipProvider
Ok, so you read the guide above and you got a server adress to the customer AD and a user in AD to use to connect with. You have modified the web.config on the site similar to this:
…and you added the connectionstring with IP or server name to connectionStrings.config like this:
…but it doesn’t work? Example of errors are:
”Unable to establish secure connection with the server” or the more evil one
”The specified domain or server could not be contacted”.
Why? Ok, let’s get this article going.
Check that ip adress is reachable
My first simple step would be to ping that adress or IP. Maybe they gave you an internal server name instead of a reachable ip or reachable url?
If ping fails, get back to the customer and let them hand you the correct ip or url.
Ok, so you get the correct ip adress of the server that you can ping. But it’s still not working? Now is the time to start downloading some additional tools. I would recommend starting with Softerra’s LDAP browser. Google it and download it. Maybe you have made some mistake on your LDAP connectionstring or the user credentials are wrong?
Testing connection to AD with Softerra LDAP browser
Booting up Softerra will give you a similar view to this. Fill in IP to test against…
and user details…
If you can browse in the AD with this tool, you now know that the both the IP and the user detail are correct.
If you got 
then you need to get in touch with the AD administrator and let him hand you the correct credentials.
You also know that the LDAP port 389 that this tool (and the ActiveDirectoryMembershipProvider) uses is open if you are able to browse in the AD at this time. It’s now time to check again if the website is able to login correctly. If not, maybe you are getting this error?
”The specified domain or server could not be contacted”
Nmap for solving firewall problems
Now it’s time to download your second tool, nmap with it’s gui part Zenmap. Google it, download it. Starting it will present you with a view similar to this
Insert your server adress at the top and hit scan. This will display a list of open ports that you can connect to on that server. The important ones that needs to be open for ActiveDirectoryMembershipProvider I’ve marked in yellow. They are 389 and 445 and yes, you need both of them.
If you don’t see port 445 in this list, this will likely generate the error
”The specified domain or server could not be contacted” when trying to login to your website.
Eureka! Contact your firewall administrators on your side and customer side and tell them to open this port, and lo, it works!
Conclusion
There are a couple of walls, some made of fire, that you can run into when setting up this type of integration. Hopefully the tools and information above should save a few hours for someone. Nmap is, by the way, also a most useful tool to locate similar integration problems when you have firewalls blocking your happiness.
The short checklist to success:
- Make sure you get a valid server adress and not an internal one. Use ping to see if the server even exist from your point of view.
- Check that both ports (389 and 445) are open between the servers (TCP). Use nmap to validate that this is true.
- Test ldap user credentials and url using LDAP browser
Happy coding!
Nice post. Always handy with a checklist list this!
Thx!
The ports specification should probably be part of the standard documentation as well but it's missing. Port 445 always gets me into trouble personally when I set this up for the first time in a while because I forget to check if it's open.
Good one! But note that security people will be really nervous about opening 445 or most likely say "no way". Also LDAP browsers that you test with will usually connect without having 445 open which makes it even more difficult to solve problems. More info here:
http://world.episerver.com/Modules/Forum/Pages/Thread.aspx?id=43724&epslanguage=en
Since port 445 is mandatory to have open if you want to use the Active Directory Membership Provider on client website I guess they will normally have to live with it. :)
Some other options though that I've seen and implemented is to either create a separate "external" slave Active Directory used for this authentication purpose and use Active Directory replication between the 2 active directories to keep them synchronized. This makes it possible to expose less information in the event of a security breach and also relieves load from a, potentially slow, internal AD.
Another "do-it-yourself" option is to have a separate webserver placed within the firewall which uses the active directory provider itself but has a WCF service or similar that client websites can connect to and validate credentials. This "relay" webserver makes it more possible to control what functionality and which ports are exposed if the network people won't let you touch parts of their precious firewall.
The client public website that needs to validate credentials etc will then need to build a custom membership- and roleprovider that uses this integration point instead. This will then work as a light weight SOA service for authentication and authorization functionality. I built this version of active directory authentication for a customer once who had some serious firewall problems that the network techs couldn't solve for a year or two. Worked well.
I have seen the slave option too - recall it was using FIM to only sync portions of the catalog.
By the way... There are some leads found when searching that 445 might only be needed to be open initially when somehow the trust is set up. It can then be closed. I haven't been able to verify this claim anywhere, but I've only done some quick testing.
EDIT: Thought I was logged in :)
I have seen the slave option too - recall it was using FIM to only sync portions of the catalog.
By the way... There are some leads found when searching that 445 might only be needed to be open initially when somehow the trust is set up. It can then be closed. I haven't been able to verify this claim anywhere, but I've only done some quick testing.
I heard that too. I wouldn't bet any money on that solution though :)