Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I set out to integrate Active Directory with the iDRAC LOM for our Dell servers. One of the prerequisites is that the Domain Controllers be SSL enabled for ldap communication. The setup process in iDRAC says Upload Active Directory CA Certificate. So I log in to one of our DCs, go to its personal certificate store, and it's empty. Up until today I've always assumed that our domain services were using SSL (I wasn't the one who set up the domain). I've never set it up before myself, and I'm not too familiar with the ins-and-outs, so the only way I know to check whether we're using SSL or not is to use wireshark on the DC and captures packets. Capturing on port 636 yielded nothing while capturing on 389 gave me all sorts of data. So at this point I'm pretty sure we're not using SSL.

So my question is, how important is it that the directory information that is transmitted back and forth be encrypted? I'm assuming that if there were an immediate risk over it not being encrypted no matter what your domain is like (whether the company is big or small with varying levels of security rules), that Microsoft would have just forced the SSL.

Obviously I would like to have AD integration with the LOM on my Dell servers, but I have some work to do before implementing it. A couple of questions I would like answers to are:

  1. What risks should I be aware of that we're facing by not using SSL
  2. If I follow one of the million guides on the internet to enable SSL, will it interrupt current service? Or will I be able to do it and the client machines will some how be informed to use SSL automatically?
  3. I have two DCs running a single domain as domain.local. Since it's an "internal" TLD, I'm guessing I'll need to set this up using an internal CA and not a third party?
  4. Based off the answer of #1, would you say it's safe to stay off of SSL? What would you feel is the ratio of benefit to effort involved in getting converted to ssl?
share|improve this question

1 Answer 1

up vote 7 down vote accepted

What risks should I be aware of that we're facing by not using SSL

Requests by domain members will use SASL (see: LDAP Security Model section in this doc)

Requests not from a domain member or client able to use SALS can be intercepted. Internally, this may not be that big of a deal since you probably have a switched network, and good control of your physical infrastructure.

If I follow one of the million guides on the internet to enable SSL, will it interrupt current service? Or will I be able to do it and the client machines will some how be informed to use SSL automatically?

It should not interrupt current service. Some clients (like your Dell LOM) will need configuration to use the SSL port, if the are currently working, and you want to enable SSL. You shouldn't have to do anything on your Windows servers/workstations.

I have two DCs running a single domain as domain.local. Since it's an "internal" TLD, I'm guessing I'll need to set this up using an internal CA and not a third party?

You can do either, you can even use a self-signed certificate. Some clients won't like this a self signed certificate, but your Drac probably would be fine with a self-signed certificate.

Setting up an enterprise CA is relatively easy, but it should really be on a box/vm just for this purpose. Can you afford a spare Windows license?

You could also run an OpenSSL CA, you could run one from a USB flash drive pretty easily. If you are familiar with Linux, then setting up an Ubuntu box/vm/usb device running tinyca should only take a couple hours.

Based off the answer of #1, would you say it's safe to stay off of SSL? What would you feel is the ratio of benefit to effort involved in getting converted to ssl?

  • If you don't trust your physical infrastructure, then you should probably enable SSL.
  • If you have a very small number of servers, then it may not be worth the effort.
  • You may be able to mitigate the risk using ipsec or some VPN to encrypt the LDAP.
  • As Evan mentioned in a comment, the DRAC LOM, is basically providing physical access, so you should strongly consider setting up SSL to protect you from a MITM.
share|improve this answer
    
+1 - I suspect the reason Dell is going for LDAP over SSL on the iDRAC is to prevent MitM attacks. Because the iDRAC is, effectively, physical access to the hardware, it makes sense to lock this down. If I were attacking your iDRAC and it wasn't using LDAP-over-SSL I'd just stand up a bogus LDAP server, ARP cache poison the iDRAC, and have my way with it. Using LDAP over SSL means that I'd have to mint a certificate to do that first and, presumably, by that point I'd already own Active Directory anyway. –  Evan Anderson Jan 25 '12 at 23:49
1  
I would have thought domain joined machines would have defaulted to using SASL/kerberos5/GSSAPI encryption. I mean to point out that he isn't currently at risk. He will be if he sets up iDRAC without SSL/TLS. –  84104 Jan 25 '12 at 23:51
2  
@84104: I agree re: domain joined PC's. The iDRAC doesn't get joined to the domain. It's probably doing a simple LDAP bind for authentication and isn't doing any Kerberos. I don't have docs in front of me but, being an embedded device I suspect that's how it is. –  Evan Anderson Jan 26 '12 at 0:24
    
@Zoredache - Thank you for the very thorough answer. It gives me the answers I was looking for. –  Safado Jan 26 '12 at 15:26
    
@Evan - You're right, it's just doing a bind and not actually joining the domain. That's a very interesting concept of setting up a rogue LDAP server and then arp poisoning the iDRAC server. Our corporate anti virus does ldap sans ssl for authentication... that might be a fun Saturday morning project to try and break into it that way. –  Safado Jan 26 '12 at 15:26

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.