-- Main.ctucker - 06 Oct 2008
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 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.
- For private key export select, No, do not export the private key
- For certificate format select, Base-64 Encoding X.509 (.cer)
- Provide a path to a new file who's name ends in .cer
- Click on the Finish button.
Right click again on the new certificate and select
Export.
- For private key export select, Yes, export the private key
- For Personal Information Exchange (.pfx) add, Include all certificates in certification path if possible
- 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.
- Provide a path to a new file who's name ends in .pfx
- 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