LDAP over SSL and other AD ports

[sonuteklists]

I found the following information in the Microsoft website regadring replication over the firewall which asked me to configure the firewall to permit the following,

Service Port/protocol
RPC endpoint mapper 135/tcp, 135/udp
NetBIOS name service 137/tcp, 137/udp
NetBIOS datagram service 138/udp
NetBIOS session service 139/tcp
RPC static port for AD
replication <fixed-port>/tcp
SMB over IP (Microsoft-DS) 445/tcp, 445/udp
LDAP 389/tcp
LDAP over SSL 636/tcp
Global catalog LDAP 3268/tcp
Global catalog LDAP over SSL 3269/tcp
Kerberos 88/tcp, 88/udp
DNS 53/tcp, 53/udp
WINS resolution (if required) 1512/tcp, 1512/udp
WINS replication (if required) 42/tcp, 42/udp

What I have to do is this,
My AD is inside a firewall. I have to let an outside application access the AD over the SECURE CHANNEL only. So,
- if I open only 636/tcp, will that be enough ??
- what other ports will I need to open, like kerberos, etc ??
- Do I have to do something to enable "LDAP over SSL" in AD ??

Again, all the application from outside the firewall has to do is to get the authentication and authorization details from the AD inside the firewall over a SECURE CHANNEL only !!

Thanks.

 

[ITPangaeaArchitect]

ive got something for you, a complete port list for AD I send to customer so often its not funny...thats why I gave it to all our DS teams for sending:

Required ports:

1024-5000 TCP/UDP – RPC (dynamic response ports) / required for RPC to respond to communications

135 TCP – RPC (endpoint mapper) / required to open the endpoint mapper to the destination for RPC communications

389 TCP/UDP – LDAP / required to bind to a DC

3268 TCP – LDAP GC / required to bind to the GC function of a domain controller (extremely important for Exchange)

53 TCP/UDP – DNS / required for name resolution and Active Directory functionality as a whole

88 TCP/UDP – Kerberos / self explanatory

445 TCP – SMB / self explanatory

123 UDP – SNTP / required for time synchronization with a time source

ICMP / required for group policy detection, application, and MTU size detection, as well as other low level activities





Optional ports:

636 TCP – LDAP SSL / required to bind to a DC using LDAP over SSL

3269 TCP – LDAP GC SSL / required to bind to a GC using LDAP over SSL

137 UDP – NetBIOS name / self explanatory

138 UDP – NetBIOS Netlogon and Browsing / self explanatory

139 TCP – NetBIOS session / self explanatory

42 TCP – WINS replication / self explanatory

1723 TCP – PPTP / required if using PPTP VPN tunnel

IP PROTOCOL 47 (GRE) – VPN related/required for PPTP VPN tunnel as well



For more information, please see:

http://support.microsoft.com/support/kb/articles/q179/4/42.asp

For Exchange considerations:

http://support.microsoft.com/?kbid=259240

http://support.microsoft.com/default.aspx?scid=kb;en-us;280132

For SQL considerations:

http://support.microsoft.com/kb/q287932/

For SMS considerations:

http://support.microsoft.com/default.aspx?scid=kb;en-us;200898

http://support.microsoft.com/kb/q167128/

-Brandon Wilson
MCSE00/03, MCSA:Messaging, MCSA03, A+
almost got a paragraph there

 

[sonuteklists]

Wow,
Thanks a bunch !!

Just one additional question. Correct me if I am wrong. If I use only LDAP authentication/authorization, then can I only open up is 389/tcp or 636/tcp. Again, all the application will do is authenticate against LDAP and retrieve the attributes and map it into its application. So to do just this, wont it be enough if I open up 389/tcp and the ones you mentioned,

1024-5000 TCP/UDP – RPC (dynamic response ports) / required for RPC to respond to communications

135 TCP – RPC (endpoint mapper) / required to open the endpoint mapper to the destination for RPC communications

The application will connect to the machine using the IP address directly.
Thanks a bunch again.

 

[ITPangaeaArchitect]

providing you are only doing a LDAP over SSL bind, 636 should be sufficient
if you get server is not operational type messages...that would indicate 53 and/or RPC ports



-Brandon Wilson
MCSE00/03, MCSA:Messaging, MCSA03, A+
almost got a paragraph there

 

[sonuteklists]

Thanks Brandon,
Please excuse my ignorance.
Re,
"if you get server is not operational type messages...that would indicate 53 and/or RPC port"
Why would this happen and what should I do ??

Also, I was following this article.

http://support.microsoft.com/default.aspx?scid=kb;en-us;321051

and while creating a certificate I got this error,
certificate request processor expected inf file extension name

What does this mean ??
Please advice.
Thanks.

 

[sonuteklists]

This is what I put and saved in the file.

----------------- request.inf ----------------- [Version] Signature="$Windows NT$ [NewRequest] Subject = "CN=<DC subdomain.domain.edu>" ; replace with the FQDN of the DC KeySpec = 1 KeyLength = 1024 ; Can be 1024, 2048, 4096, 8192, or 16384. ; Larger key sizes are more secure, but have ; a greater impact on performance. Exportable = TRUE MachineKeySet = TRUE SMIME = False PrivateKeyArchive = FALSE UserProtected = FALSE UseExistingKeySet = FALSE ProviderName = "Microsoft RSA SChannel Cryptographic Provider" ProviderType = 12 RequestType = PKCS10 KeyUsage = 0xa0 [EnhancedKeyUsageExtension] OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication -----------------------------------------------

Basicall I copied everything. Please excuse me as I am ignorant and havent dont this before.
If the domain is say subdomain.domain.edu, what should the file say.
Please advice asap.
Thanks a bunch.

 

[ITPangaeaArchitect]

ok so you are talking for the cert here

so here comes some mroe questions for you

how is your CA setup? Are you using MS CA with public cert for SSL, or just using that cert?
people are going to be accessing your CA by a public domain name most likely, which means you need to have an alternative subject name of teh fqdn of the internal CA (or DC), as well as teh common name being the public domain name..in addition to that you need to ensure you have teh public and private key in teh cert to give to users

-Brandon Wilson
MCSE00/03, MCSA:Messaging, MCSA03, A+
almost got a paragraph there

 

[sonuteklists]

I actually dont have the CA here, I was going to use someone else' CA.

Dunno about the setting they have !!
I can set a MS CA up just for testing purpose. What do you suggest ? Could you provide a link for that and in general to understand the CA.
Also, I dont fully understand,
"Are you using MS CA with public cert for SSL, or just using that cert?"

The domain I am going to use is a test domain on a test DC and so not public. Also can you give me how this would look,

- have an alternative subject name of teh fqdn of the internal CA (or DC)

- common name being the public domain name

I guess I would eventually have this,
"public and private key in teh cert to give to users"
when everything is setup right.

Could you also answer the following with regards to AD. I am still learning the ropes and I come across stuff which I dont fully understand. What does the following mean (I dont fully remember the context, but once I understand I guess I can piece things together),
- privileged DN that can search for and find users in the AD based on username
- samAccountName in AD
- how to set up AD so that users are not anonymously
searchable in AD (if it is default, how not to then?)
- Configured AD to allow users to bind to the LDAP directory as themselves to verify the credential
- base of your LDAP directory
(LDAP suffix/subtree under which the users are located)
Again, I am learning the ropes and come across these terms often among various documents. Can you explain all these in simple terms what they mean with an example. Even a doc, link would be ok. But your personal tip would be best.

Again, thanks for all your help and for dumbing down the information so that I can understand. All your help is greatly appreciated. You are truly the God of AD, sometime in this decade maybe I will have all those certs !!

Thanks a bunch.

 

[ITPangaeaArchitect]

The CA subject is very vast

i would suggest looking at the windows 2000 or windows 2003 websites(whichever is applicable to you) and look up PKI in there to get that info

using an ASN does requrie a change to teh CA in order to use it, FYI..we have not made anything public on it frmo MS as it is normally handled by the thrid party cert vendor

just be sure you have the ASN and teh public and private key

i can tell you now your inf for the request is not correct for using an ASN...but again, there a wide varying array of circumstances when you do not need to use one, and one may fit you...that will take alot of research on your part...now as far as your questions:



- privileged DN that can search for and find users in the AD based on username
**not sure what you mean here...a DN is a distinguished name, and every object in AD has them..my guess is that this means a user account capable of searching AD...a normal domain user has these privileges

- samAccountName in AD
*samAccountName is an attribute on user accounts, it is created for all user accounts and is part of what keeps duplicate accounts from being created

- how to set up AD so that users are not anonymously
searchable in AD (if it is default, how not to then?)
*if you are running Win2003, by default, users cannot anonymously bind or view AD..teh setting is a security option in the default domain controllers policy (do not allow anonymous connections)...if it is not set to this, you either have a Win2000 domain, or else somebody changed this

- Configured AD to allow users to bind to the LDAP directory as themselves to verify the credential
*this is the default and is required, so not sure what you mean here

- base of your LDAP directory
(LDAP suffix/subtree under which the users are located)
*this varies based on OU structure, teh default is "cn=users,dc=domain,dc=com"


-Brandon Wilson
MCSE00/03, MCSA:Messaging, MCSA03, A+
almost got a paragraph there

 

[ITPangaeaArchitect]

add on---cn=users is not the base of AD tree, it is the domain (if you are at the forest root)

teh base dn is dc=domain,dc=com

-Brandon Wilson
MCSE00/03, MCSA:Messaging, MCSA03, A+
almost got a paragraph there

 

[NickFerrar]

I'd check out this article and consider using IPSEC instead of blowing your firewall wide open

http://www.microsoft.com/serviceproviders/columns/config_ipsec_p63623.asp

 

[sonuteklists]

ADGod,
One clarification regarding,
" privileged DN that can search for and find users in the AD based on username
**not sure what you mean here...a DN is a distinguished name, and every object in AD has them..my guess is that this means a user account capable of searching AD...a normal domain user has these privileges"
I just want to double-confirm this. The AD user account in question needs to be able to retrieve info (attributes) about all the users in AD, not just itself, so do you still think a normal domain user would have the rights. Do I have to define a special set of privs for this purpose ??
Please advice.
Thanks.

 

[sonuteklists]

Ok, I finally could get it to work.
Again, I followed the following link,

http://support.microsoft.com/default.aspx?scid=kb;en-us;321051

I rebooted the server. But one thing, when from another server, I tried the ldp.exe utility to test the domain over port 636 and "ssl" option checked, I got the following error,

ld = ldap_sslinit("10.1.2.11", 636, 1);
Error <0x0> = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, LDAP_VERSION3);
Error <0x51> = ldap_connect(hLdap, NULL);
Server error: <empty>
Error <0x51>: Fail to connect to 10.1.2.11.

When I unchecked "ssl" and tried again on port 636 I got,
ld = ldap_open("10.1.2.11", 636);
Error <0x51>: Fail to connect to 10.1.2.11.

I am not sure what this this means. Does this mean that LDAPS is not working. If not what do I do.
I checked the other troubleshooting steps mentioned in the link, but either they dont apply or dont work.

Please advice.
Thanks.

 

[sonuteklists]

I am sorry. I did try the netbios name, fqdn as well as IP address.
I am wondering if there is anything else I should enable. I havent changed anything in the default domain and domain controller policy.
Thanks.