This is still a work in progress. Major editing will be taking place for some time.

Active Directory Account Management And Setting User Passwords Over A Secure LDAP Connection (THIS PAGE NEEDS UPDATING)

This document will outline how to manage Active Directory user account properties, including how to set user passwords, from a Solaris management host (cscf.cs in our case) which may not necessarily be a member of the Active Directory. This process will involve the use of a Certificate Authority and personal certificates to handle authentication of authorized accounts management users. Using the Certificate Authority mechanism eliminates the need for maintaining and securing clear text passwords needed for binding to the Active Directory LDAP servers.

The Solaris Management host will require the OpenLDAP 2.3 package (with SASL/EXTERNAL authentication enabled) and OpenSSL 0.9.8 to be installed.

This document also assumes the existence of a Certificate Authority for the Active Directory forest. Details on establishing Certificate Authority and Secure LDAP are outlined in the ADLdapS wiki page. CSCF's Active Directory utilizes its own forest based Certificate Authority instead of the Certificate Authority supplied by University of Waterloo's IST department.

Create An Accounts Management User Account Within The Active Directory

To create such a user account you will require the following.

• Domain Admin rights within the domain where the new management account will be a member.

We call it cscf_accounts_client and it is a user account in the CSCF-SYSADMINS domain in CSCF's forest.

This account will serve as the go between from the Solaris management host to our Active Directory (AD). When an AD user account requires creation or update, the Solaris management host will connect to the appropriate domain controller via LDAP using the credentials of this new account. This account does not necessarily have to reside in the same domain as the accounts it is intended to manage. In our case we've created the account in the CSCF-SYSADMINS domain although it is intended to manage general user account in only the CS-TEACHING and CS-GENERAL domains.

When prompted to set a password for this account, provide some long complex password. Since we intend to utilize this account through the forest's Certificate Authority (CA), the value of this password is not very important since it will rarely be used. Also, ensure that the following items are set in the Accounts tab for the account properties.

• User cannot change password
• Password never expires
• Account expires is set to Never

This account does not require any permanently assigned special privileges within the CSCF-SYSADMINS domain. It does require account management privileges within the CS-TEACHING and CS-GENERAL domains. This is why the cscf-accounts-cllient user is assigned membership in the account_cs group in both domains. It does NOT require nor should it have permanent Domain Admin membership in any domain.

Create Authentication Certificates For The AD's Accounts Management Account From The Certificate Authority

At the present time, common users may not request user certificates from our AD's Certificate Authority. The reason for this is not yet understood. However, Domain Administrators in all domains can request User certificates for themselves. Hence while creating certificates for the cscf_accounts_client account we need to make it a member of the Domain Admins group for the CSCF-SYSADMINS domain. Once the certificates are exported this membership can be revoked without effecting the authentication abilities of the certificates.

In this section we will be requesting a User certificate from our AD's Certificate Authority (CA) for the cscf_accounts_client user account. With this certificate we will then export it into file form using two separate formats.

As the cscf_accounts_client user (here you will need this account's complex password), start the Microsoft Management Console.

runas /user:cscf-sysadmins\cscf_accounts_client mmc.exe

Load the Certificates snap-in and, when prompted, select My user account.

Request A New User Certificate

Within the the Certificates snap-in, select the Personal folder and right click in the empty right pane. Select All Tasks -> Request A New Certificate. Follow through with the wizard's instructions, you will be creating a User certificate (usually the only option). Provide a Friendly Name and Description for the new certificate, these can be anything but the Friendly Name should be short and unique. Finally, click Finish.

If successful the new user certificate will appear in the Personal -> Certificates folder of the Certificates snap-in.

Export The User Certificate Into File Format

Now we shall commence two separate export operations of this certificate. We will be creating two separate files, one for user identification and the other a key. Both these files when used together can authenticate for the cscf_accounts_client account. The certificates are also immune to a password change for the account they represent. As such it is vital that both these new files be kept secure. If they end up in the wrong hands then the certificate upon which they were created will have to be revoked and a new certificate issued.

Right click on the new certificate and select Export.

1. For private key export select, No, do not export the private key
2. For certificate format select, Base-64 Encoding X.509 (.cer)
3. Provide a path to a new file who's name ends in .cer
4. Click on the Finish button.

Right click again on the new certificate and select Export.

1. For private key export select, Yes, export the private key
2. For Personal Information Exchange (.pfx) add, Include all certificates in certification path if possible
3. DO NOT provide a password, leave these fields blank.
   This password is intended as a mechanism for securing the usage of the private key. However, current OpenLDAP tools cannot use this feature. Further, these certificates will be used only by authorized users on the Solaris Management host.
4. Provide a path to a new file who's name ends in .pfx
5. Click on the Finish button.

Securely transfer both the .cer and .pfx files to the Solaris Management host. Ensure only authorized users on the Solaris system have rights to read these files.

Name Map Exported .cer Certificate To User's Account

It is our understanding that a certificate generated by a user does not require name mapping in order for it to be used for authenticating the account which created it. However, name mapping of the X.509 .cer file to the user account may be tried as a diagnostic tool. Common users cannot map certificates to their own accounts so this process must be done by someone with Accounts Management or Domain Administrator privileges within the domain of the account in question - cscf_accounts_client in our case.

Remove the cscf_accounts_client account from the Domain Admins group.

Set Up Account Management Account On Solaris Management System

By default, the Solaris account responsible for account management could be root, but it could be a dedicated common user account whose sole purpose is to manage Active Directory accounts from the management server.

Convert Key Certificate From pfx To pem Format

OpenLDAP functions cannot read the pfx key certificate format supplied by the Active Directory CA. Therefore once the certificate is copied over to the Solaris management host, it must be converted into pem format using OpenSSL. This is done using the following command at a Solaris command prompt.

@cscf[104]% openssl pkcs12 -in path_to_AD_account_manager_key_certificate_pfx_file -out path_to_AD_account_manager_key_certificate_new_pem_file -nodes

Create An .ldaprc File For The Solaris Accounts Manager

The .ldaprc file is created in the home directory of the Solaris user that will be responsible for AD accounts management. This file is comparable to the system's /etc/ldap.conf file but allows for personalization of LDAP features like the use of personal user certificates. In order to use the imported user certificates for securing and authenticating LDAP connections, the .ldaprc file must contain the following lines.

TLS_CACERT path_to_Certificate_Authority_certificate_cer_file 
TLS_CERT path_to_AD_account_manager_user_certificate_another_cer_file 
TLS_KEY path_to_AD_account_manager_key_certificate_new_pem_file 
TLS_REQCERT demand

The creation and obtaining of the certificate listed in the TLS_CACERT line is outlined in the ADLdapS wiki page. This certificate is responsible for establishing the trust of the Active Directory's Certificate Authority. It is this certificate that allows the creation of a secure LDAP connection from the Solaris Management host to the Active Directory domain controllers. It does not however, provide an authenticated connection under a specific username, that part is done by the TLS_CERT and TLS_KEY certificate files created previously in this document.

With the certificate files in place and the .ldaprc file configured, the OpenLDAP functions should be able to securely bind to our Active Directory as CSCF-SYSADMINS\cscf_accounts_client without the need of a manually entered password or maintained password file.

Examples Of Account Management Operations Using Certificates And OpenLDAP

Modifying User Account Attributes

The following Solaris command will change the Display Name of user ctucker in the CS-GENERAL (cs.uwaterloo.ca) domain from its current value to Fred. The first line is the actual modify command where the LDAP server must be specified in full qualified form (intacta.cs or other aliases will not work). The remaining lines are LDIF commands which ldapmodify reads to perform the modification of a specified LDAP object (AD user account in this case) attribute - displayName.

The ldapmodify command will first consult the contents of .ldaprc and use any specified certificates to attempt to first establish a secure connection to the LDAP server (intacta.cs.uwaterloo.ca in this case) and then use the user credentials to bind to the LDAP database. Neither the binding name or a password needs to be specified in the command line. No binding passwords are used at all.

@cscf[104]% /software/ldapopen_server/bin/ldapmodify -ZZ -h intacta.cs.uwaterloo.ca << EOF
dn: cn=ctucker,ou=Test User,ou=Unassigned,dc=cs,dc=uwaterloo,dc=ca
changetype: modify
replace: displayName
displayName: Fred
EOF

The output of which demonstrates that user cscf_accounts_client is authenticated using SASL and then under the authority of this account, the object ctucker (cn=ctucker,ou=Test User,ou=Unassigned,dc=cs,dc=uwaterloo,dc=ca) is modified.

SASL/EXTERNAL authentication started
SASL username: CN=cscf_accounts_client,OU=Special Accounts,OU=CSCF,DC=sysadmins,DC=cscf,DC=uwaterloo,DC=ca
SASL SSF: 0
modifying entry "cn=ctucker,ou=Test User,ou=Unassigned,dc=cs,dc=uwaterloo,dc=ca"

Setting A User Password

Setting a user password in secured LDAP is just like setting any other object attribute in principle. The difficulty arises with this specific attribute - unicodePwd. This attribute cannot be read except by an AD domain controller SYSTEM, but it can be over written by authorized users if the new data is correctly encoded. To encode a new password for use in the unicodePwd attribute, I discovered the following env script on the web.

From: http://lists.samba.org/archive/samba/2004-August/091134.html

#!/usr/bin/env ruby

require "base64"

def cleartext2unicode(cleartextpwd)
  quotepwd = '"' + cleartextpwd + '"'
  unicodepwd = quotepwd.split('').join("\0") + "\0"
  return Base64.encode64(unicodepwd)
end

if ARGV.length == 1
  cleartextpwd = ARGV.shift
  puts "unicodePwd::" + cleartext2unicode(cleartextpwd)
end

Accepting a new password string in plain text as input, the output of this script is a text string of the form unicodePwd::encoded_password which can be used directly in the LDIF commands in ldapmodify as demonstrated below.

@cscf[104]% /software/ldapopen_server/bin/ldapmodify -ZZ -h intacta.cs.uwaterloo.ca << EOF
dn: cn=ctucker,ou=Test User,ou=Unassigned,dc=cs,dc=uwaterloo,dc=ca
changetype: modify
replace: unicodePwd
unicodePwd::encoded_password
EOF

Creating A New User

This next example demonstrates how to create a brand new user account named jquser with some standard CSCF default characteristics. This account will come into existence enabled with a set initial password and instructions to force a password change upon next user logon. The account will have a specific expiry date set. And the new user will automatically be assigned to the domain's Users group.

The accountExpires attribute represents the expiry date for the new account. It is a 64-bit integer counting the number of 100 nanosecond intervals since the start (midnight) of 1 Jan 1601 AD local time - no kidding!. The expiry date used for this example is calculated to be the end of 16 Nov 2008 AD.

@cscf[110]% /software/ldapopen_server/bin/ldapadd -ZZ -h intacta.cs.uwaterloo.ca << EOF
dn: cn=jquser,ou=Test User,ou=Unassigned,dc=cs,dc=uwaterloo,dc=ca
displayName: John Q. User
objectClass: user
sAMAccountName: jquser
userPrincipalName: jquser@cs.uwaterloo.ca
unicodePwd::encoded_initial_password
userAccountControl: 512
pwdLastSet: 0
accountExpires: 128714086010000000
homeDirectory: \\\smb-files.cs\jquser
homeDrive: P:
profilePath: \\\smb-files.cs\jquser\WindowsTSProfile
loginShell: /xhbin/csh
gidNumber: 60300
uidNumber: 60301
unixHomeDirectory: /u/jquser
EOF

Adding A User To An Existing Group

For this example we will assign the newly created user jquser to the sponsor_cscf group within the AD. All accounts managed by automation are members of this group.

@cscf[105]% /software/ldapopen_server/bin/ldapadd -ZZ -h intacta.cs.uwaterloo.ca << EOF
dn: cn=sponsor_cscf,ou=CSCF,ou=CS,dc=cs,dc=uwaterloo,dc=ca
changetype: modify
add: member
member: cn=jquser,ou=Test User,ou=Unassigned,dc=cs,dc=uwaterloo,dc=ca
EOF

Creating A New User, A New Group And Assigning Group Membership At The Same Time

For CSCF purposes, every new user created requires a new personal user group associated with that user (for Solaris and Linux operations) and membership in one or more existing AD security group - sponsor_cscf in particular but also potential coarse groups. The LDIF command sequence below creates the jquser user account followed by his personal user group jquser_group (CSCF requires the displayName attribute to be set to the username - jquser). jquser is not actually made a member of jquser_group as this is not needed. However, jquser is made a member of the existing group sponsor_cscf and potentially other existing coarse groups.

The blank lines in the LDIF sequence below are not typos. They are part of the LDIF syntax to distinguish between separated LDAP actions. In this case, those actions are the creation of the new jquser account, the creation of the new jquser_group personal user group and the modification of the sponsor_cscf group with the addition of the new username. Also note that it is the group object sponsor_cscf that is modified and not the user jquser when group assignment occurs.

@cscf[109]% /software/ldapopen_server/bin/ldapadd -ZZ -h intacta.cs.uwaterloo.ca << EOF
dn: cn=jquser,ou=Test User,ou=Unassigned,dc=cs,dc=uwaterloo,dc=ca
displayName: John Q. User
objectClass: user
sAMAccountName: jquser
userPrincipalName: jquser@cs.uwaterloo.ca
unicodePwd::encoded_initial_password
userAccountControl: 512
pwdLastSet: 0
accountExpires: 128714086010000000
homeDirectory: \\\smb-files.cs\jquser
homeDrive: P:
profilePath: \\\smb-files.cs\jquser\WindowsTSProfile
loginShell: /xhbin/csh
gidNumber: 60300
uidNumber: 60301
unixHomeDirectory: /u/jquser

dn: cn=jquser_group,ou=Solaris Groups,ou=CS,dc=cs,dc=uwaterloo,dc=ca
objectClass: group
displayName: jquser
gidNumber: 60300

dn: cn=sponsor_cscf,ou=CSCF,ou=CS,dc=cs,dc=uwaterloo,dc=ca
changetype: modify
add: member
member: cn=jquser,ou=Test User,ou=Unassigned,dc=cs,dc=uwaterloo,dc=ca
EOF