Users Guide

• The domain controller addresses congured in iDRAC does not match the Subject or Subject Alternative Name of the directory
server certicate. If you are using an IP address, read the next question. If you are using FQDN, make sure you are using the
FQDN of the domain controller and not the domain. For example, servername.example.com instead of example.com.
Certicate validation fails even if IP address is used as the domain controller address. How to resolve this?
Check the Subject or Subject Alternative Name eld of your domain controller certicate. Normally, Active Directory uses the host
name and not the IP address of the domain controller in the Subject or Subject Alternative Name eld of the domain controller
certicate. To resolve this, do any of the following:
• Congure the host name (FQDN) of the domain controller as the domain controller address(es) on iDRAC to match the Subject
or Subject Alternative Name of the server certicate.
• Reissue the server certicate to use an IP address in the Subject or Subject Alternative Name eld, so that it matches the IP
address congured in iDRAC.
• Disable certicate validation if you choose to trust this domain controller without certicate validation during the SSL handshake.
How to congure the domain controller address(es) when using extended schema in a multiple domain environment?
This must be the host name (FQDN) or the IP address of the domain controller(s) that serves the domain in which the iDRAC object
resides.
When to congure Global Catalog Address(es)?
If you are using standard schema and the users and role groups are from dierent domains, Global Catalog Address(es) are required.
In this case, you can use only Universal Group.
If you are using standard schema and all the users and role groups are in the same domain, Global Catalog Address(es) are not
required.
If you are using extended schema, the Global Catalog Address is not used.
How does standard schema query work?
iDRAC connects to the congured domain controller address(es) rst. If the user and role groups are in that domain, the privileges
are saved.
If Global Controller Address(es) is congured, iDRAC continues to query the Global Catalog. If additional privileges are retrieved from
the Global Catalog, these privileges are accumulated.
Does iDRAC always use LDAP over SSL?
Yes. All the transportation is over secure port 636 and/or 3269. During test setting, iDRAC does a LDAP CONNECT only to isolate
the problem, but it does not do an LDAP BIND on an insecure connection.
Why does iDRAC enable certicate validation by default?
iDRAC enforces strong security to ensure the identity of the domain controller that iDRAC connects to. Without certicate
validation, a hacker can spoof a domain controller and hijack the SSL connection. If you choose to trust all the domain controllers in
your security boundary without certicate validation, you can disable it through the Web interface or RACADM.
Does iDRAC support the NetBIOS name?
Not in this release.
Why does it take up to four minutes to log in to iDRAC using Active Directory Single Sign–On or Smart Card Login?
The Active Directory Single Sign–On or Smart Card log in normally takes less than 10 seconds, but it may take up to four minutes to
log in if you have specied the preferred DNS server and the alternate DNS server, and the preferred DNS server has failed. DNS
time-outs are expected when a DNS server is down. iDRAC logs you in using the alternate DNS server.
291