How to Enable LDAP Directory Services Authentication to Microsoft Active Directory in the HP cClass Onboard Administrator

I.

Certificate Services a. Install a Certificate Authority onto a Windows server in the domain (Control Panel/Add Remove Programs/Windows Components). The CA must be set to process new cert requests automatically. For Enterprise Root CAs, this is the only option. For Stand-alone CAs, it is set in: Admin Tools/Certification Authority/Right click the CA/Properties. Click the Policy Module and the configure button. The Default Action tab will be displayed. Set the Always issue the certificate to on. * HP strongly suggests you use an Enterprise root CA as the process for DCs to request and accept DC certificates from stand alone CAs is not trivial.

II.

Preparing the Directory Some liberty can be taken with the names used here, but if this is the first time you are doing this, you should follow these steps so that you understand how the process works. Once you have the hang of it, you can alter the names and locations, etc. For a normal customer install, these types of groups already exist. a. Create a Windows group called OA Admins and put a user called Admin in this group. OS level permissions are not important for this user (i.e. he does not need to be a member of Administrators in AD or anything for this to work). b. Create a group called OA Operators and put a user called Operator in this group. Again, OS level permissions are not important for this user (i.e. he does not need to be a member of Administrators in AD or anything for this to work). For the purposes of this paper, well call this user operator

III.

Preparing the OA a. Navigate to the Directory Settings screen located under Users/ Authentications for the desired enclosure.

IV.

b. Click to Enable LDAP and enter in the IP address or name of one of your DCs. This DC MUST be accepting LDAP connections over SSL (636 is the default port for LDAP over SSL in MS AD and it could possibly be an alternate port if it was changed). See the Troubleshooting section (below) for more information on verifying that this works. Alternatively, you could enter the domain name of your AD domain (DOMAIN.COM) instead of a server name. Entering a domain name by itself will cause the DNS servers defined for the domain to offer DCs in a round robin fashion offering some sort of load balancing as well as allowing OA to still login in LDAP users if a certain DC is offline. For simplicity during initial setup, HP recommends you use just a single IP address. c. The Search Context is standard LDAP Format. For example, if your user accounts are in the Users OU in a domain called BLADEDEMO.HP.COM, the Search Context would look like this: CN=Users,DC=bladedemo,DC=hp,DC=com d. You may want to also add the ability to use NT style names by checking the box titled Use NT Account name Mapping. e. Click Apply Uploading the DC Certificate

Multiple DC certificates may be uploaded. For now, just upload the one that you know is allowing LDAP over SSL that was used in Step III. a. Click the Upload Certificate Tab as shown below.

b. Obtain the certificate from the DC by opening a new web browser window to https://<domain_controller>:636 (substitute <domain_controller> for your DC). Note that this is an HTTPS URL and not an HTTP URL. It should prompt you for accepting a certificate as shown below. Click View Certificate

c. Click the Details Tab and click the Copy to File button as shown below.

d. As shown below, select Base-64 encoded x.509 (.CER) from the list of export options (this is important). Provide a name and location for the file (c:\dccert.cer) and finish the wizard.

e. Locate the exported certificate file in explorer and rename it to a .txt extension (dccert.txt). Open the file in notepad and copy the entire contents to the clipboard. It will be something similar to this:

-----BEGIN CERTIFICATE----MIIFxDCCBKygAwIBAgIKJWUSwAAAAAAAAjANBgkqhkiG9w0BAQUFADBVMRMwEQYK CZImiZPyLGQBGRYDY29tMRIwEAYKCZImiZPyLGQBGRYCaHAxFzAVBgoJkiaJk/Is ZAEZFgdhdGxkZW1vMREwDwYDVQQDEwh3aW5kb3pDQTAeFw0wNjA4MjIyMDIzMTFa Fw0wNzA4MjIyMDIzMTFaMCAxHjAcBgNVBAMTFXdpbmRvei5hdGxkZW1vLmhwLmNv bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAy4zeh3iXydUAWKVHIDsxLJ6B aRuVT9ZhkL5NQHIDeRjumsgc/jHSERDmHuyoY/qbF7JMhJ9Lh9QQHUg8QfEYsC1y qTvgisrZeHtvmrmecvSxZm27b4Bj5XYN0VYcrwqKnH7X/tVhmwqGls7/YZyahNU1 lGB2OjoCq5eJxX+Ybx0CAwEAAaOCA00wggNJMAsGA1UdDwQEAwIFoDBEBgkqhkiG 9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4D output truncated -----END CERTIFICATE-----

f. Return to the OA Upload Certificate screen and paste the certificate contents into the window and click Upload. V. Creating Directory Groups The way that users are authenticated and privileges are assigned is by first verifying that the username and password given to OA match the credentials in the Directory. Once verified, OA queries the Directory to find what Active Directory groups the user is a member of. It then matches those Group names against the Directory Group names that exist in OA. We will create these OA Directory Groups in this step. The group name is used to determine LDAP users' group membership and must match one of the following five properties of a directory group: the name, distinguished name, common name, Display Name, or SAM Account Name. a. In OA, navigate to the Users/Authentications/Directory Groups link. b. Click New to add a new directory group. c. First, create a group called OA Admins which matches the name we created in Active Directory. i. Give this group full administrative privileges over all server bays and interconnect bay an click Add as shown below.

d. Create a Second Directory Group called OA Operators to match the operator group we created in Active Directory. This time, give the group Operator privilege level instead of Administrator and do not give the group access to Server Bays but do allow access to Interconnect bays and click Add as shown below:

VI.

Testing the Directory Login solution You have now completed everything needed to make the solution work. To test the solution, logoff the current session of OA and close all browser windows. Browse to the OA, and attempt to login using one of these formats: Admin Admin@domain.com DOMAIN\Admin And enter the corresponding password you used for this user account. The login should succeed and you should have full Administrative privileges. If the long does not succeed, see the troubleshooting section later in this paper. Now, logoff or sign out of OA and attempt to login is as Operator using one of the following formats: Operator Operator@Domain.com DOMAIN\Operator And the corresponding password you used for this account. This should succeed and you should have no access to any Server Blades, but full access to Interconnect Bays.

Troubleshooting: If you are having trouble authenticating, the following steps might help: I. Testing SSL A simple test to see that SSL is working on the DCs in your domain is to open a browser and navigating to https://<domain_controller>:636 (substitute your DC for <domain_controller>). You can substitute <domain> in place of <domain controller> which will go to DNS in a round robin fashion to see which DC is currently handling requests for the domain. It might be helpful to test multiple DCs to see that all of them have been issued a certificate. If SSL is operating properly on a DC (i.e. a Certificate has been issued to it), you will be prompted by the Security dialog asking if you want to proceed with accessing the site, or view the servers certificate. Note that clicking Yes will not yield a web page - this is normal. The test is simply to get prompted to accept the Security Dialog. A server not listening on 636 will simply go right to a page cannot be displayed message. If this test fails, it means that your DC is not accepting SSL connections because it probably has not been issued a certificate. This process is supposed to be automatic, but requires a reboot in some cases. To avoid the reboot, you can force this to happen by following these steps: 1. Open the MMC and add the Certificates snap-in. When prompted, choose Computer Account for the type of certificates you want to view. Click OK to return to the Certificates snap in. 2. Navigate to Personal->Certificates folder. Right click the folder and choose Request New Certificate. They type should already be Domain Controller and click Next until it issues the certificate. A second method for testing this is to go to the DC itself and run the following command: C:\netstat -an | find /i "636" If the server is listening for requests on port 636, you should see this response: TCP 0.0.0.0:636 0.0.0.0:0 LISTENING

A third method of testing SSL is to use the Microsoft tool called LDP. More information on LDP can be found at www.microsoft.com II. Removing old Certificates. In some cases, an old certificate may be present on the DC that points to a previously trusted CA with the same name. This usually doesnt happen unless Certificate Services is added and removed and then added again. To resolve this, use the method in Step 1 above and refer to the HP Customer Advisory EM030604_CW01 listed here:

http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=PSD_EM 030604_CW01 A third problem could be that the domain controllers have not autoenrolled. The DCs take up to 8 hours to autoenroll and get their certificates issued because MS uses GPO to make the DCs aware of the newly installed CA. You can force this by running DSSTORE pulse from the DCs (tool is in the w2k reskit). It is triggered by winlogon, so for autoenrollment to work, you may need to log off and logon. You are supposed to be able to see the certs show up automatically in the CAs Issues Certs list if this process worked (make sure the CA is not listing them in Pending Certs if it is, you may want to change the CA to auto issue certs when a request comes in). If the autoenrollment feature STILL doesnt work, you may need to request the cert yourself like this: On the DC, open MMC and add in Certificate Snap-in (Computer Account) Navigate to Personal and right click the folder. Click Request New Cert and click next, next, etc. Enter a friendly name for the cert. If you receive and RPC error, check that the CA is listed in DNS (even if you can ping the CA) and that the CA is running. If you receive an error saying that the wizard could not be started try this to force the server to see the CA and allow the wizard to run: To speed up the GPO process and make the DCs acknowledge the CA, do the following: For 2k3 Gpupdate /force For 2k Secedit /refreshpolicy machine_policy /enforce Check that the OA has all of the proper network settings (like DNS) and that the time and date are correct (Certificates are date sensitive). Make sure OA can reach the DNS server (ping it from the OA command line interface).