I need to join computers to our Active Directory domain. These computers are on an untrusted network.
How can I force the client computers to use secure protocols (LDAPS instead of LDAP) to join the domain?
Ldap – How to securely join computers in an Active Directory domain in an untrusted network
active-directoryldap
Related Solutions
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
I agree with the other posters who say that you need a network layer solution, but I disagree with the advice to use a VPN client. This adds complexity and, if you're looking for the clients on the untrusted network to apply group policy during startup, it's likely not possible with a VPN client.
The domain join (and authentication, in general) would be the least of my concerns when operating clients on an untrusted network. I'd be much more concerned with plaintext traffic to your file servers, application servers, etc. Network layer encryption and authentication is in order, to my mind.
IPSEC is what you're looking for here. Deploying an IPSEC policy on your domain controller computers that requires IPSEC communication to the subnets where the untrusted clients are located (ideally, also applying to your member server computers the clients will be communicating with as well) is the first step.
The second step is to use the AuthIP protocol to join clients to the domain securely. AuthIP allows clients to establish IPSEC connectivity with domain controller during the domain join process. AuthIP is, unfortunately, fairly poorly documented by Microsoft. It's been in the Windows Server and client products since Windows Vista.
Another option might be a DirectAccess VPN (which works "transparently" and doesn't require executing a client program) along with offline Domain Join to bootstrap the clients into the domain and get them using DirectAccess. DirectAccess is IPSEC-based (IPv6 tunneled over an untrusted IPv4 or IPv6 network to your trusted LAN), so you get network layer encryption and authentication using this method, too.