This has been a fun topic of discussion on Server Fault. There appear to be varying "religious views" on the topic.
I agree with Microsoft's recommendation: Use a sub-domain of the company's already-registered Internet domain name.
So, if you own foo.com, use ad.foo.com or some such.
The most vile thing, as I see it, is using the registered Internet domain name, verbatim, for the Active Directory domain name. This causes you to be forced to manually copy records from the Internet DNS (like www) into the Active Directory DNS zone to allow "external" names to resolve. I've seen utterly silly things like IIS installed on every DC in an organization running a web site that does a redirect such that someone entering foo.com into their browser would be redirected to www.foo.com by these IIS installations. Utter silliness!
Using the Internet domain name gains you no advantages, but creates "make work" every time you change the IP addresses that external host names refer to. (Try using geographically load-balanced DNS for the external hosts and integrating that with such a "split DNS" situation, too! Gee-- that would be fun...)
Using such a subdomain has no effect on things like Exchange email delivery or User Principal Name (UPN) suffixes, BTW. (I often see those both cited as excuses for using the Internet domain name as the AD domain name.)
I also see the excuse "lots of big companies do it". Large companies can make boneheaded decisions as easily (if not moreso) than small companies. I don't buy that just because a large company makes a bad decision that somehow causes it to be a good decision.
The ASP.NET Active Directory Membership Provider does an authenticated bind to the Active Directory using a specified username, password, and "connection string". The connection string is made up of the LDAP server's name, and the fully-qualified path of the container object where the user specified is located.
The connection string begins with the URI LDAP://.
For the server name, you can use the name of a domain controller in that domain-- let's say "dc1.corp.domain.com". That gives us LDAP://dc1.corp.domain.com/ thusfar.
The next bit is the fully qualified path of the container object where the binding user is located. Let's say you're using the "Administrator" account and your domain's name is "corp.domain.com". The "Administrator" account is in a container named "Users" located one level below the root of the domain. Thus, the fully qualified DN of the "Users" container would be: CN=Users,DC=corp,DC=domain,DC=com. If the user you're binding with is in an OU, instead of a container, the path would include "OU=ou-name".
So, using an account in an OU named Service Accounts that's a sub-OU of an OU named Corp Objects that's a sub-OU of a domain named corp.domain.com would have a fully-qualified path of OU=Service Accounts,OU=Corp Objects,DC=corp,DC=domain,DC=com.
Combine the LDAP://dc1.corp.domain.com/ with the fully qualified path to the container where the binding user is located (like, say, LDAP://dc1.corp.domain.com/OU=Service Accounts,OU=Corp Objects,DC=corp,DC=domain,DC=com) and you've got your "connection string".
(You can use the domain's name in the connection string as opposed to the name of a domain controller. The difference is that the domain's name will resolve to the IP address of any domain controller in the domain. That can be both good and bad. You're not reliant on any single domain controller to be up and running for the membership provider to work, but the name happens to resolve to, say, a DC in a remote location with spotty network connectivity then you may have problems with the membership provider working.)
Best Answer
You are to be commended both for thinking about security and for understanding the implications of setting TLS_REQCERT.
You can use the
openssltool to do this. Assuming that you can access Active Directory via LDAP-over-SSL on port 636, you could do this:And when the command completes, you'll find that output contains, among other things, the PEM encoded certificate:
You can remove everything before the
BEGIN CERTIFICATEline and everything after theEND CERTIFICATE LINEand you should have what you're looking for.It's also possible that the AD server is not using a self-signed certificate but is instead using a certificate issued by the AD certificate authority. If this is the case, it might be easier just to ask the AD folks for the CA certificate.