Unsolved

This post is more than 5 years old

14 Posts

62760

June 16th, 2008 16:00

DRAC Active Directory Config

I have been trying (and failing) at getting our DRAC's (v4 & v5) integrated into AD for user authentication.  Is there something I am missing to get this to work?  I believe I am following the instruction properly.

 

1) Extended the AD Schema via the Dell GUI

2) Created DRAC objects for access groups in Computers and Users

3) Created DRAC objects for cards

4) Exported our AD Root CA Certificate

5) Verified the Domain Security Policy was set for all domain controllers to have Root CA Cert Auto-Enrolled

6) Configured DRAC, Imported Domains Root CA Cert

7) Tried logon, and repeatedly fails when using AD Credentials.

 

I guess it would be helpful if there was some expanded logs to look at.  The DRAC logs are worthless as they only report (Logon Failed).

 

Can some provide better/more clear instructions than the Dell CD Manual?  Tricks to getting this to work? Or a way to get better information from the DRAC on what actually failing when AD credentials are used?

 

Thanks!

206 Posts

June 16th, 2008 19:00

The DRACs have a tracelog that could give you an indication of the problem.  Go to the diagnostics tab and type 'gettracelog'  or from the command line 'racadm gettracelog'

206 Posts

June 16th, 2008 20:00

if you are using the self signed web server cert that ships with the drac or if you are issuing a signed cert to every drac, either way they need to be in the trusted root certification authorities store on every DC.  This is to complete the sSL chain. 

 

see 'Importing the DRAC 5 Firmware SSL Certificate' here 

<ADMIN NOTE: Broken link has been removed from this post by Dell>

14 Posts

June 16th, 2008 20:00

Thats what I thought.  The trace logs show my authentication requests bouncing all around AD and it happens to each of the DC's that I have not yet installed the DRAC5 cert on.

 

I'll get busy and get this cert install on the remainder of the DC's and see what happens.

14 Posts

June 16th, 2008 20:00

Jay,

 

Thanks...much more useful information in the trace log!  Okay this next question I think I know the answer for per what I now see in the tracelogs but I want to ask anyway...does the DRAC Firmware SSL Cert need to be loaded on ALL Domain Controllers in the domain or just the ones with a DRAC installed?  I am guess it needs to be on all servers whether it has a DRAC or not in order to authenticate.

 

Mike

206 Posts

June 17th, 2008 03:00

I am sure your tracelog says something like 'can't init ldap'.  I get that alot.  Some things to remember:

 

1:  When you export the enterprise root certificate it MUST be just that:  The certificate from the enterprise root CA.  Most companies have this machine offline to protect the private key.  You will have to turn this machine on and go to the personal cert store and find the cert with the word 'all' under the intended purposes column.  That is the cert that needs to be exported base 64 x.509 and imported into every drac under the AD section. 

2:  Don't get the enterprise root cert confused with the web server cert.  There are 2 certs in play here that are part of the SSL chain.

3:  If you have revoked an enterprise root cert you may have to pulse the domain controllers.

1.       Configure AD Auto-enrollment

a.       Log into A Domain controller open Active Directory Users and computers.

b.      Right click Domain controllers -> properties -> Group Policy tab -> Select "Default Domain Controller Policy" -> edit

c.       Computer Configuration -> Windows Settings -> Security Settings -> Select Public Key policies

d.      Double Click AutoEnrollment Settings, check both check boxes

e.      Right Click Automatic Certificate Enrollment -> New -> Automatic Certificate Request

f.        Next -> Domain Controller -> Next Finish

g.       Click ok to get out of Group policy edit and Active Directory Users and Computers

 

2.       Renew Certificates on domain controllers

a.       From CMD.exe on each DC run:

b.      certutil -dcinfo deletebad

c.       GPUPDATE /force

d.      certutil -pulse

 

14 Posts

June 17th, 2008 15:00

Okay...I have the DRAC5 SSL Cert on all DC's and it appears as if I am getting further along.  To me it appears as if I am searching the AD with LDAP, but something is going amuck.  I am not sure, but I think I might also have a config issue with the AD setup on the DRAC.  Here is the trace log, any suggestions?

 

-------------------------------------------------------------------------------
Record:      224
Date/Time:   Jun 17 11:50:51
Source:      webcgi[3849]
Description: AD login start 10.55.36.116 '011694@firstbusey.corp' ssn 681894f7
-------------------------------------------------------------------------------
Record:      225
Date/Time:   Jun 17 11:50:51
Source:      webcgi[3850]
Description: ActiveDirectoryAuthenticate: user: 011694, domain: firstbusey.corp
-------------------------------------------------------------------------------
Record:      226
Date/Time:   Jun 17 11:50:51
Source:      webcgi[3850]
Description: racDomain: firstbusey.corp, racName: rac-fschafox01, rootDomain: firstbusey.corp
-------------------------------------------------------------------------------
Record:      227
Date/Time:   Jun 17 11:50:51
Source:      webcgi[3850]
Description: userDomain: firstbusey.corp
-------------------------------------------------------------------------------
Record:      228
Date/Time:   Jun 17 11:50:51
Source:      webcgi[3850]
Description: SRV.0 has hostname=fsgibsa01.firstbusey.corp, ipaddr.0=a32a370a, port=389
-------------------------------------------------------------------------------
Record:      229
Date/Time:   Jun 17 11:50:51
Source:      webcgi[3850]
Description: SRV.1 has hostname=fsengin01.firstbusey.corp, ipaddr.0=8221370a, port=389
-------------------------------------------------------------------------------
Record:      230
Date/Time:   Jun 17 11:50:51
Source:      webcgi[3850]
Description: AD server: fsgibsa01.firstbusey.corp, IP: a32a370a
-------------------------------------------------------------------------------
Record:      231
Date/Time:   Jun 17 11:50:51
Source:      webcgi[3850]
Description: ldap_ssl_init( fsgibsa01.firstbusey.corp, 636 )
-------------------------------------------------------------------------------
Record:      232
Date/Time:   Jun 17 11:50:51
Source:      webcgi[3850]
Description: ldap_query: SD: base_dn=DC=firstbusey,DC=corp, userDN=CN=Douglas\, Michael,OU=Users,OU=IT,DC=firstbusey,DC=corp, rac_dev=rac-fschafox01, racDomain=firstbusey.corp
-------------------------------------------------------------------------------
Record:      233
Date/Time:   Jun 17 11:50:51
Source:      webcgi[3850]
Description: ldap_query.c,463: ldap_search_ext: Bad search filter (-7)
-------------------------------------------------------------------------------
Record:      234
Date/Time:   Jun 17 11:50:51
Source:      webcgi[3850]
Description: SD: fsgibsa01.firstbusey.corp, IP: a32a370a, port: 636, prv: 0, rt: 0
-------------------------------------------------------------------------------
Record:      235
Date/Time:   Jun 17 11:50:51
Source:      webcgi[3850]
Description: SRV.0 has hostname=fsfoxop10.firstbusey.corp, ipaddr.0=2861a8c0, port=3268
-------------------------------------------------------------------------------
Record:      236
Date/Time:   Jun 17 11:50:51
Source:      webcgi[3850]
Description: SRV.1 has hostname=fspeoku01.firstbusey.corp, ipaddr.0=422b370a, port=3268
-------------------------------------------------------------------------------
Record:      237
Date/Time:   Jun 17 11:50:51
Source:      webcgi[3850]
Description: GC server: fsfoxop10.firstbusey.corp, IP: 2861a8c0
-------------------------------------------------------------------------------
Record:      238
Date/Time:   Jun 17 11:50:51
Source:      webcgi[3850]
Description: ldapGCGetAOList: GC: fsfoxop10.firstbusey.corp, IP: 2861a8c0, port: 3269
-------------------------------------------------------------------------------
Record:      239
Date/Time:   Jun 17 11:50:51
Source:      webcgi[3850]
Description: userFullName: 011694@firstbusey.corp
-------------------------------------------------------------------------------
Record:      240
Date/Time:   Jun 17 11:50:51
Source:      webcgi[3850]
Description: ldap_ssl_init( fsfoxop10.firstbusey.corp, 3269 )
-------------------------------------------------------------------------------
Record:      241
Date/Time:   Jun 17 11:50:51
Source:      webcgi[3850]
Description: ldap_query.c,463: ldap_search_ext: Bad search filter (-7)
-------------------------------------------------------------------------------
Record:      242
Date/Time:   Jun 17 11:50:51
Source:      webcgi[3850]
Description: 2008 login failed from 10.55.36.116: '011694@firstbusey.corp'
-------------------------------------------------------------------------------
Record:      243
Date/Time:   Jun 17 11:50:51
Source:      webcgi[3850]
Description: login failed from 10.55.36.116: '011694@firstbusey.corp', ActiveDirectoryAuthenticate rc=00006007
-------------------------------------------------------------------------------
Record:      244
Date/Time:   Jun 17 11:50:51
Source:      webcgi[3850]
Description: AD login finish 10.55.36.116 '011694@firstbusey.corp' idx 1  sid 681894f7  error 24583 (0x6007)
-------------------------------------------------------------------------------
Record:      245
Date/Time:   Jun 17 11:51:04
Source:      webcgi[3853]
Description: 2008 012919 login  from 10.55.36.116
-------------------------------------------------------------------------------
Record:      246
Date/Time:   Jun 17 11:51:04
Source:      webcgi[3853]
Description: 012919 login  from 10.55.36.116  idx 2  sid 29b54739
-------------------------------------------------------------------------------

206 Posts

June 17th, 2008 17:00

What firmware version?  Display name was physically keyed into ad users and computers when the account was created like this Douglas, Michael

 

The problem is the comma.  CN=Douglas\, Michael  It is being escaped out (the \ )

 

DRAC 5 firware v1.33 should fix this http://tinyurl.com/698ey6

 

14 Posts

June 17th, 2008 18:00

Looks like I am out of date on the FW, currently at v1.21.  Downloading new FW now.  Thanks for all the help!

 

Got a few more questions...I also have DRAC v4 Cards...firmware update for these is almost a given, so I will go search for the latests in a few minutes.  What about the DRAC4 SSL Cert?  Will the DRAC5 Cert be inclusive for previous DRAC releases or will I need to add the DRAC4 SSL Cert to my DC's as well?

14 Posts

June 17th, 2008 18:00

Jay,

 

I greately appreaciate all your help!  The new FW did the trick on the DRAC5 cards and I am now successfully authenticating into them via AD credentials.

 

I will repeat my process with the DRAC4 and hopefully I will have one task off my list today!

 

Thanks a bunch!!!

 

-Mike

206 Posts

June 17th, 2008 18:00

I think DRAC 4 v1.60 will address the commas being escaped in the common name.

http://tinyurl.com/6du65o

 

We are currently working on a new DRAC 4 v1.61 and it is currently in the testing phase.  Should release in July.

 

The self signed web server cert on the drac 4 is different from the drac 5 (totally different versions of apache) so that cert will need to go on your DCs as well.

 

 

14 Posts

June 18th, 2008 17:00

I don't think the DRAC4 FW v1.60 fixes the AD parsing issue.  From the trace logs I see the same thing as I had seen on the DRAC5 before upgrading it's firmware.

 ------------------------------------------------------------------------------------

Jun 18 13:56:22.12 LOG_INFO: Nameservers: 2, 192.168.20.160, 10.55.43.2
Jun 18 13:56:22.12 LOG_DEBUG: SRV.2 has hostname=fsurbma01.firstbusey.corp, ipaddr.1=0, port=389
Jun 18 13:56:22.12 LOG_DEBUG: SRV.2 has hostname=fsurbma01.firstbusey.corp, ipaddr.0=222370a, port=389
Jun 18 13:56:22.12 LOG_INFO: AD server: fsblmha01.firstbusey.corp, IP: e22a370a
Jun 18 13:56:22.12 LOG_NOTICE: ldap_ssl_init( fsblmha01.firstbusey.corp, 636 )
Jun 18 13:56:36.53 LOG_DEBUG: ldap_query: SD: base_dn=DC=firstbusey,DC=corp, userDN=CN=Douglas\, Michael,OU=Users,OU=IT,DC=firstbusey,DC=corp, rac_dev=rac-chafoap9, racDomain=firstbusey.corp
Jun 18 13:56:36.54 LOG_ERR: ldap_query.c,434: ldap_search_ext: Bad search filter (87)
Jun 18 13:56:36.55 LOG_INFO: SD: fsblmha01.firstbusey.corp, IP: e22a370a, port: 636, prv: 0, rt: 0
Jun 18 13:56:36.55 LOG_INFO: No match found during AD search, now we will go through Global Catalog servers
Jun 18 13:56:36.55 LOG_INFO: Nameservers: 2, 192.168.20.160, 10.55.43.2
Jun 18 13:56:36.56 LOG_INFO: Nameservers: 2, 192.168.20.160, 10.55.43.2
Jun 18 13:56:36.58 LOG_DEBUG: SRV.0 has hostname=fslerce01.firstbusey.corp, ipaddr.1=0, port=3268
Jun 18 13:56:36.58 LOG_DEBUG: SRV.0 has hostname=fslerce01.firstbusey.corp, ipaddr.0=8329370a, port=3268
Jun 18 13:56:36.58 LOG_INFO: Nameservers: 2, 192.168.20.160, 10.55.43.2
Jun 18 13:56:36.59 LOG_DEBUG: SRV.1 has hostname=fsptcmu01.firstbusey.corp, ipaddr.1=0, port=3268
Jun 18 13:56:36.59 LOG_DEBUG: SRV.1 has hostname=fsptcmu01.firstbusey.corp, ipaddr.0=c220370a, port=3268
Jun 18 13:56:36.59 LOG_INFO: Nameservers: 2, 192.168.20.160, 10.55.43.2
Jun 18 13:56:36.60 LOG_DEBUG: SRV.2 has hostname=fsfaith01.firstbusey.corp, ipaddr.1=0, port=3268
Jun 18 13:56:36.60 LOG_DEBUG: SRV.2 has hostname=fsfaith01.firstbusey.corp, ipaddr.0=f22a370a, port=3268
Jun 18 13:56:36.60 LOG_INFO: GC server: fslerce01.firstbusey.corp, IP: 8329370a
Jun 18 13:56:36.60 LOG_DEBUG: ldapGCGetAOList: GC: fslerce01.firstbusey.corp, IP: 8329370a, port: 3269
Jun 18 13:56:36.60 LOG_DEBUG: userFullName: 011694@firstbusey.corp
Jun 18 13:56:36.60 LOG_NOTICE: ldap_ssl_init( fslerce01.firstbusey.corp, 3269 )
Jun 18 13:56:50.51 LOG_ERR: ldap_query.c,434: ldap_search_ext: Bad search filter (87)
Jun 18 13:56:50.56 LOG_INFO: AD Auth: user '011694' dom 'firstbusey.corp'  fail  rc=0x40090007
Jun 18 13:57:02.67 LOG_NOTICE: ssnmgr: session id 0x40faaa6 not found
Jun 18 13:57:02.68 LOG_NOTICE: ssnmgr: session id 0x40faaa6 not found

206 Posts

June 18th, 2008 18:00

I was afraid of that.  The 1.61 version is supposed to be released in July.  You can create a new ad account, just don't key a comma into the display name when you create the account and it should work.

14 Posts

June 19th, 2008 12:00

I'll keep an eye open for 1.6.1, until then I will rename the accounts and remove the comma's for the the System Admins using the DRAC's.

14 Posts

August 14th, 2008 13:00

Any word on the release of the DRAC4 firmware update that fixes the issue with parsing AD Credentials with a comma?  Nothing ever materialized in July and my management team is asking how much longer until we have a solution in place.

 

We currently created "shared" logins for the dracs in AD as a workaround, but our regulatory authorities do not like shared accounts and we need to get these removed before our next audit.

 

Any new release date available?

206 Posts

August 14th, 2008 13:00

It has been delayed, I suspect to have it soon. 

 

Just found out it will be released with our September block release on September 22nd.

Message Edited by DELL-JamesC on 08-14-2008 09:39 AM
No Events found!

Top