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?
Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.Sign up to join this community
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.
There is no way to force LDAPS over LDAP except by port blocking. Ldaps isn't really the solution you need here though. I don't believe Domain Joins (with windows xp+ workstations) use simple bind to connect.
It's important to remember that only LDAP data transfers are exposed. Other authentication or authorization data using Kerberos, SASL, and even NTLM have their own encryption systems. So you aren't really compromising your join account and password.
If you need it the following Article explains how to configure LDAPS in a windows domain but again it is really only needed when you are third-partying AD access.
This needs to be addressed at the network layer. As uslackr recommended, you can use a VPN to create a network connection that is secure.
LDAP is only one of many protocols that may be required, and this would be a mess to try to fix at the os-level.
LDAP tcp/389 udp/389 LDAP for Global Catalog tcp/3268 NetBIOS (if used) 137, 138, 139 CIFS tcp/445 udp/445 LDAPS tcp/636 LDAPS for Global Catalog tcp/3269 NTP tcp/123 RPC Dynamic (all ports above 49152 in Windows 7, or above 1024 in Windows 2003) RPC Endpoint Mapper tcp/135 DNS tcp/53 udp/53 Kerberos tcp/88 (may also need udp/88 if not forcing kerberos over tcp)