Users Guide

• The Group Name and Group Domain Name matches the Active Directory conguration if you are using standard schema.
• If the user and the iDRAC object is in dierent domain, then do not select the User Domain from Login option. Instead select
Specify a Domain option and enter the domain name where the iDRAC object resides.
• Check the domain controller SSL certicates to make sure that the iDRAC time is within the valid period of the certicate.
Active Directory login fails even if certicate validation is enabled. The test results display the following error message. Why does this
occur and how to resolve this?
ERROR: Can't contact LDAP server, error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed: Please check the correct
Certificate Authority (CA) certificate has been uploaded to iDRAC. Please also check if the
iDRAC date is within the valid period of the certificates and if the Domain Controller Address
configured in iDRAC matches the subject of the Directory Server Certificate.
If certicate validation is enabled, when iDRAC establishes the SSL connection with the directory server, iDRAC uses the uploaded CA
certicate to verify the directory server certicate. The most common reasons for failing certication validation are:
• iDRAC date is not within the validity period of the server certicate or CA certicate. Check the iDRAC time and the validity period of
your certicate.
• 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?
Frequently asked questions
317