Active
Directory login failed. How to resolve this?
To diagnose
the problem, on the
Active Directory Configuration and
Management
page, click
Test Settings. Review the test results and fix the problem. Change the configuration
and run the test until the test user passes the authorization step.
In general, check the following:
- While logging in, make sure that you use the correct user domain
name and not the NetBIOS name. If you have a local iDRAC7 user account,
log into iDRAC7 using the local credentials. After logging in, make
sure that:
- The
Enable Active Directory option is selected
on the
Active Directory Configuration and Management page.
- The DNS setting is correct on the
iDRAC7 Networking
configuration
page.
- The correct Active Directory root CA certificate is uploaded
to iDRAC7 if certificate validation was enabled.
- The iDRAC name and iDRAC Domain name matches the Active Directory
environment configuration if you are using extended schema.
- The Group Name and Group Domain Name matches the Active Directory
configuration if you are using standard schema.
- Check the domain controller SSL certificates to make sure that
the iDRAC7 time is within the valid period of the certificate.
Active
Directory login fails even if certificate 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 iDRAC7. Please also check if the iDRAC7 date
is within the valid period of the certificates and if the Domain Controller Address configured in iDRAC7 matches the subject
of the Directory Server Certificate.
If certificate validation is enabled, when iDRAC7 establishes
the SSL connection with the directory server, iDRAC7 uses the uploaded
CA certificate to verify the directory server certificate. The most
common reasons for failing certification validation are:
- iDRAC7 date is not within the validity period of the server certificate
or CA certificate. Check the iDRAC7 time and the validity period of
your certificate.
- The domain controller addresses configured in iDRAC7 does not
match the Subject or Subject Alternative Name of the directory server
certificate. 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.
Certificate
validation fails even if IP address is used as the domain controller
address. How to resolve this?
Check the Subject or Subject
Alternative Name field of your domain controller certificate. Normally,
Active Directory uses the host name and not the IP address of the
domain controller in the Subject or Subject Alternative Name field
of the domain controller certificate. To resolve this, do any of the
following:
- Configure the host name (FQDN) of the domain controller as the
domain controller address(es) on iDRAC7 to match the Subject
or Subject Alternative Name of the server certificate.
- Reissue the server certificate to use an IP address in the Subject
or Subject Alternative Name field, so that it matches the IP address
configured in iDRAC7.
- Disable certificate validation if you choose to trust this domain
controller without certificate validation during the SSL handshake.
How
to configure 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 iDRAC7 object resides.
When
to configure Global Catalog Address(es)?
If you are using
standard schema and the users and role groups are from different 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?
iDRAC7 connects to the
configured domain controller address(es) first. If the user and role
groups are in that domain, the privileges are saved.
If Global
Controller Address(es) is configured, iDRAC7 continues to query the
Global Catalog. If additional privileges are retrieved from the Global
Catalog, these privileges are accumulated.
Does
iDRAC7 always use LDAP over SSL?
Yes. All the transportation
is over secure port 636 and/or 3269. During test setting, iDRAC7 does
a LDAP CONNECT only to isolate the problem, but it does not do an
LDAP BIND on an insecure connection.
Why
does iDRAC7 enable certificate validation by default?
iDRAC7
enforces strong security to ensure the identity of the domain controller
that iDRAC7 connects to. Without certificate 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 certificate validation, you can disable it through the Web
interface or RACADM.
Does
iDRAC7 support the NetBIOS name?
Not in this release.
Why
does it take up to four minutes to log in to iDRAC7 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 specified
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. iDRAC7 logs you in using the alternate DNS server.
The
Active Directory is configured for a domain present in Windows Server
2008 Active Directory. A child or sub domain is present for the domain,
the user and group is present in the same child domain, and the user
is a member of that group. When trying to log in to iDRAC7 using the
user present in the child domain, Active Directory Single Sign-On
login fails.
This may be because of the an incorrect group
type. There are two kinds of Group types in the Active Directory server:
- Security — Security groups allow you to manage user and computer
access to shared resources and to filter group policy settings.
- Distribution — Distribution groups are intended to be used only
as email distribution lists.
Always make sure that the group type is Security. You
cannot use distribution groups to assign permission on any object,
however use them to filter group policy settings.