In our last post we discussed regarding the configuring Windows box to hold UNIX related attributes for LDAP authentication. We proceed to discuss the steps to join a Solaris 10 box into Active Directory.
The Solaris client must join an Active Directory domain to use Active Directory for security and directory services. The adjoin.sh script automates the domain join operation by executing the following steps from the Solaris client:
· Auto-detects the Active Directory domain controller
· Creates a machine account (also called a Computer object) for the Solaris host in Active Directory and generates a random password for this account
· Configures the Solaris host as a Kerberos client of the Active Directory domain controller by using the /etc/krb5/krb5.conf file
· Configures the /etc/krb5/krb5.keytab file on the Solaris host by using the keys for the machine account (also called host credentials)
The adjoin.sh script uses the ksetpw binary to set the password for the machine account and to configure the local keytab file. Run adjoin -h to see the options supported by the adjoin.sh script. This script requires proper DNS configuration on the client. Therefore, /etc/resolv.conf must point to the correct DNS domain and servers, and /etc/nsswitch.conf must use DNS for host resolution. Ensure that the ksetpw binary is in the same directory as adjoin.sh.
My testing around this shows that until I used the adjoin.sh script from adjoin-s10u5.tar.gz from http://jp.opensolaris.org/os/project/winchester/files/ ; it was hitting an error like “cannot join the active directory”.
I have configured my /etc/resolv.conf file to have the Active Directory domain name and name server to my DNS server’s IP.
bash-3.00# cat /etc/resolv.conf
domain win2k3r2dc1.sfu
nameserver x.x.x.x
Also, to the /etc/nsswitch.conf file was configured to use dns to find the hosts.
bash-3.00# egrep "hosts|ipnodes" /etc/nsswitch.conf
hosts: dns ldap [NOTFOUND=return] files
ipnodes: dns ldap [NOTFOUND=return] files
The following adjoin.sh example output is for a Solaris host, sfusol101, that tries to join an Active Directory domain, win2k3r2dc1.sfu, that is served by the Active Directory domain controller, sfu2k3r2dc1.win2k3r2dc1.sfu. The -f option forces the creation of a machine account for sfusol101 even if one already exists. If a machine account already exists, the existing account is first removed before being recreated.
bash-3.00# ./adjoin -f
Joining domain: win2k3r2dc1.sfu
Looking for domain controllers and global catalogs (A RRs)
Looking for KDCs and DCs (SRV RRs)
KDCs = sfu2k3r2dc1.win2k3r2dc1.sfu 88
DCs = sfu2k3r2dc1.win2k3r2dc1.sfu 389
Password for Administrator@WIN2K3R2DC1.SFU:
Looking for forest name
Forest name = win2k3r2dc1.sfu
Looking for Global Catalog servers
Looking for site name
Looking for subnet object in the global catalog
Could not find site name for any local subnet
Site name not found. Local DCs/GCs will not be discovered
Looking to see if there's an existing account...
Looking to see if the machine account contains other objects...
Deleting existing machine account...
Creating the machine account in AD via LDAP
adding new entry CN=SFUSOL101,CN=Computers,DC=win2k3r2dc1,DC=sfu
Setting the password/keys of the machine account
Result: success (0)
Getting kvno
KVNO: 2
Determining supported enctypes for machine account via LDAP
This must not be a Longhorn/Vista AD DC!
So we assume 1DES and arcfour enctypes
ARCFOUR will be supported
Finishing machine account
modifying entry CN=SFUSOL101,CN=Computers,DC=win2k3r2dc1,DC=sfu
adjoin: Done
At this point we should be able to see a new computer object for the Solaris 10 box in the Active Directory and Computer snap-in.
The contents of the krb5.conf file should be as follows:
bash-3.00# cat /etc/krb5/krb5.conf
[libdefaults]
default_realm = WIN2K3R2DC1.SFU
[realms]
WIN2K3R2DC1.SFU = {
kdc = sfu2k3r2dc1.win2k3r2dc1.sfu
kpasswd_server = sfu2k3r2dc1.win2k3r2dc1.sfu
kpasswd_protocol = SET_CHANGE
admin_server = sfu2k3r2dc1.win2k3r2dc1.sfu
}
[domain_realm]
.win2k3r2dc1.sfu = WIN2K3R2DC1.SFU
Use the ldapsearch command for a user to ensure the presence of POSIX attributes. In the following output, the attributes in bold were added by Identity Management for UNIX and those in italics are the SFU attributes. Actual output only shows one set of attributes. The example shows both sets to highlight the attribute names.
bash-3.00# ldapsearch -h sfu2k3r2dc1.win2k3r2dc1.sfu -b "cn=users,dc=win2k3r2dc1,dc=sfu" -o mech=gssapi -o authzid='' "cn=user1"
version: 1
dn: CN=user1,CN=Users,DC=win2k3r2dc1,DC=sfu
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: user1
givenName: user1
distinguishedName: CN=user1,CN=Users,DC=win2k3r2dc1,DC=sfu
instanceType: 4
whenCreated: 20090410193520.0Z
whenChanged: 20090410081004.0Z
displayName: user1
uSNCreated: 20496
uSNChanged: 20556
name: user1
objectGUID:: 6PoklKVrN0+YBxKg5WPgiA==
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 128843237708750000
pwdLastSet: 128838246047656250
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAOdXTkrp7Y/6sP9sfVQQAAA==
accountExpires: 9223372036854775807
logonCount: 2
sAMAccountName: user1
sAMAccountType: 805306368
userPrincipalName: user1@win2k3r2dc1.sfu
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=win2k3r2dc1,DC=sfu
uid: user1
msSFU30Name: user1
msSFU30NisDomain: win2k3r2dc1
uidNumber: 10000
gidNumber: 10000
unixHomeDirectory: /home/user1
loginShell: /bin/sh
The next step is to initializing the Solaris LDAP Client
Now we configure the Solaris host as an LDAP client of Active Directory, which allows the Solaris host to access naming service information from Active Directory. As prerequisites, the DNS client and nscd should be enabled, and the /etc/resolv.conf file should be properly configured. Verify that both forward and reverse DNS lookup of the Active Directory server succeeds from the Solaris host, as shown in the following example. If reverse DNS lookup fails, then add a PTR record for the Active Directory server to the DNS server, if it does not exist. Modify /etc/nsswitch.ldap to use DNS for hosts and ipnodes. Unlike earlier versions, nscd in the Solaris 10 08/07 release supports enhanced LDAP connection management and improved caching. We must enable nscd to use the per-user authentication functionality as follows:
bash-3.00# svcadm enable svc:/network/dns/client:default
bash-3.00# svcadm enable name-service-cache
bash-3.00# dig sfu2k3r2dc1.win2k3r2dc1.sfu +short
<output should be IP address of the domain controller>
bash-3.00# dig -x <IP address of the domain controller +short
sfu2k3r2dc1.win2k3r2dc1.sfu.
bash-3.00# grep dns /etc/nsswitch.ldap
hosts: dns ldap [NOTFOUND=return] files
ipnodes: dns ldap [NOTFOUND=return] files
In the following example, Microsoft Windows Server 2003 Enterprise Edition R2 has UNIX related attributes enabled.
bash-3.00# ldapclient -v manual \
-a credentialLevel=self \
-a authenticationMethod=sasl/gssapi \
-a defaultSearchBase=dc=win2k3r2dc1,dc=sfu \
-a domainName=win2k3r2dc1,dc=sfu\
-a defaultServerList=<ip adress of the domain controller> \
-a attributeMap=passwd:gecos=cn \
-a attributeMap=passwd:homedirectory=unixHomeDirectory \
-a objectClassMap=group:posixGroup=group \
-a objectClassMap=passwd:posixAccount=user \
-a objectClassMap=shadow:shadowAccount=user \
-a serviceSearchDescriptor=passwd:cn=users,dc=win2k3r2dc1,dc=sfu?one \
-a serviceSearchDescriptor=group:cn=users,dc=win2k3r2dc1,dc=sfu?one
Let’s restart the LDAP client.
bash-3.00# svcadm restart svc:/network/ldap/client:default
And verify the contents of the LDAP client cache.
bash-3.00# ldapclient list
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_SERVERS= <IP address of the domain controller>
NS_LDAP_SEARCH_BASEDN= dc=win2k3r2dc1,dc=sfu
NS_LDAP_AUTH= sasl/GSSAPI
NS_LDAP_CACHETTL= 0
NS_LDAP_CREDENTIAL_LEVEL= self
NS_LDAP_SERVICE_SEARCH_DESC= passwd:cn=users,dc=win2k3r2dc1,dc=sfu?one
NS_LDAP_SERVICE_SEARCH_DESC= group:cn=users,dc=win2k3r2dc1,dc=sfu?one
NS_LDAP_ATTRIBUTEMAP= passwd:gecos=cn
NS_LDAP_ATTRIBUTEMAP= passwd:homedirectory=unixHomeDirectory
NS_LDAP_OBJECTCLASSMAP= group:posixGroup=group
NS_LDAP_OBJECTCLASSMAP= passwd:posixAccount=user
NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=user
Using the Naming Service Switch and Pluggable Authentication Modules (PAM).
The following /etc/nsswitch.conf file configures the Solaris client to use Active Directory for users and groups, DNS for host resolution, and local files for other naming service lookups:
bash-3.00# cat /etc/nsswitch.conf
passwd: files ldap
group: files ldap
hosts: dns ldap [NOTFOUND=return] files
ipnodes: dns ldap [NOTFOUND=return] files
networks: ldap [NOTFOUND=return] files
protocols: ldap [NOTFOUND=return] files
rpc: ldap [NOTFOUND=return] files
ethers: ldap [NOTFOUND=return] files
netmasks: ldap [NOTFOUND=return] files
bootparams: ldap [NOTFOUND=return] files
publickey: ldap [NOTFOUND=return] files
netgroup: ldap
automount: files ldap
aliases: files ldap
services: files ldap
printers: user files ldap
auth_attr: files ldap
prof_attr: files ldap
project: files ldap
tnrhtp: files ldap
tnrhdb: files ldap
Use the pam_krb5.so.1 module in the /etc/pam.conf file to enable authentication, account management, and password management on the Solaris client by using Active Directory through Kerberos. Minimally, enable the module for login and other services. The following /etc/pam.conf file authenticates users by using Active Directory through Kerberos and authenticates through the UNIX login only if the Kerberos authentication fails (see the auth entries). This arrangement is helpful when a majority of the users are in Active Directory and when there are only a few non-Active Directory user accounts, such as root. The account entries check for password expiration when dealing with Active Directory and local UNIX password-aging policies. The password entries change the Active Directory password of the user and continue to change the local UNIX password only if the Active Directory password change fails.
login auth requisite pam_authtok_get.so.1
login auth required pam_dhkeys.so.1
login auth required pam_unix_cred.so.1
login auth sufficient pam_krb5.so.1
login auth required pam_unix_auth.so.1
login auth required pam_dial_auth.so.1
other auth requisite pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth required pam_unix_cred.so.1
other auth sufficient pam_krb5.so.1
other auth required pam_unix_auth.so.1
other account requisite pam_roles.so.1
other account required pam_unix_account.so.1
other account required pam_krb5.so.1
other password required pam_dhkeys.so.1
other password requisite pam_authtok_get.so.1
other password requisite pam_authtok_check.so.1
other password sufficient pam_krb5.so.1
other password required pam_authtok_store.so.1
Time to test the client
Let’s test the configuration by running the getent command for the passwd database for a particular user. If this command does not return the user, the client configuration failed. The /var/adm/messages file traps related errors.
bash-3.00# getent passwd user1
user1:x:10000:10000:user1:/home/user1:/bin/sh
We can use the ldaplist command to search for and list naming information. Note that running the ldaplist -l command returns a Critical Extension not found error, but if we specify an Active Directory user, you should get the correct output. The critical extension error occurs because Active Directory does not support some of the LDAP Version 3 extensions that are used by the Solaris LDAP client. In particular, Active Directory does not support the extension that is required for virtual list view (VLV) indexes.
bash-3.00# ldaplist -l passwd user1
dn: gecos=user1,gecos=Users,DC=win2k3r2dc1,DC=sfu
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: posixAccount
cn: user1
givenName: user1
distinguishedName: CN=user1,CN=Users,DC=win2k3r2dc1,DC=sfu
instanceType: 4
whenCreated: 20090410193520.0Z
whenChanged: 20090410081004.0Z
displayName: user1
uSNCreated: 20496
uSNChanged: 20556
name: user1
objectGUID: #
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 128843237708750000
pwdLastSet: 128838246047656250
primaryGroupID: 513
objectSid: #
accountExpires: 9223372036854775807
logonCount: 2
sAMAccountName: user1
sAMAccountType: 805306368
userPrincipalName: user1@win2k3r2dc1.sfu
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=win2k3r2dc1,DC=sfu
uid: user1
msSFU30Name: user1
msSFU30NisDomain: win2k3r2dc1
uidNumber: 10000
gidNumber: 10000
homedirectory: /home/user1
loginShell: /bin/sh
gecos: user1
Note: The objectGUID and objectSID attributes in the ldaplist output have binary values.
Verify that if we can log in successfully to the Solaris client as an Active Directory user by using ssh. Home directories that are shared by an NFS server can be automatically mounted at login time by configuring automount on the Solaris client.
In Windows 2003 R2 the active directory schema is RFC 2307 compliant particularly to hold the UNIX related attributes. This feature can be used to populate related attributes for objects like users, groups etc. An UNIX client like Solaris or Red Hat Linux 4 now take the full advantage of these attributes when configured to bind and talk to Active Directory using LDAP. Users can be authenticated against the Active Directory from these *NIX boxes. We will discuss the step-by-step (both Windows and *NIX environment) procedures to achieve this.
On a windows 2003 R2 we need a group, a user and populate the attributes. Once the group and users are created, the values for the attributes can be added any tool that allows us to interact directly with the schema like adsiedit. A simple vb script can also perform the same.
List of attributes for a group:
gidNumber – an unique number for the group in a domain
List of attributes for a user:
uid – generally the sAMAccountName
uidNumber – an unique number for the user in a domain
gidNumber – number same as of the gidNumber of the group to which this user belongs
msSFU30Name - generally the sAMAccountName
unixHomeDirectory – home directory for UNIX environment
loginShell – default shell for user
I am including a sample script to populate these attributes using a vb script here. To run it properly we need to put the correct domain name. Populating the group information can also be done by modifying this script.
A popular approach is to install “Identity Management for UNIX” and the use the UNIX attribute tab in the properties page of users and group to populate these attributes. But, this method forces us to add a value to “msSFU30NisDomain” attribute which is not all used in this whole scenario. If keeping this extra amount of data in the schema does not ring any bell, we can use this straight forward method.
on error resume next
Const ADS_SCOPE_SUBTREE = 2
Const ADS_PROPERTY_CLEAR = 1
Const ADS_PROPERTY_UPDATE = 2
dim samname,uidnumber
samname= InputBox("Enter SAMAccountName :")
Set objConnection = CreateObject("ADODB.Connection")
Set objCommand = CreateObject("ADODB.Command")
objConnection.Provider = "ADsDSOObject"
objConnection.Open "Active Directory Provider"
Set objCOmmand.ActiveConnection = objConnection
objCommand.CommandText = "Select distinguishedname from 'LDAP://DC=<xxx>,DC=<xxx>' " & "where objectCategory='person' and objectclass='user' and samaccountname='" & samname & "'"
objCommand.Properties("Page Size") = 1000
objCommand.Properties("Timeout") = 30
objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE
objCommand.Properties("Cache Results") = False
Set objRecordSet = objCommand.Execute
objRecordSet.MoveFirst
Do Until objRecordSet.EOF
strUserDN = objRecordSet.Fields("distinguishedname").Value
set objuser = GetObject("LDAP://" & strUserDN & "")
uid = ""
objuser.GetInfoEx Array("uid", "sn"), 0
For Each value in objuser.GetEx("uid")
uid = uid & "" & value & ";"
Next
uid = Mid(uid,1,len(uid)-1)
uid = InputBox("Please Enter the value for the Uid value","",uid)
pos=InStr(uid,";")
if pos <> 0 and not isempty(uid) then
uidarray = Split(uid,";")
dim strarr()
dim i
For i = lbound(uidarray) to ubound(uidarray)
redim preserve strarr(i)
strarr(i) = uidarray(i)
Next
if (ubound(uidarray)>=0) then
objuser.PutEx ADS_PROPERTY_CLEAR,"uid", 0
objuser.SetInfo
objuser.GetInfoEx Array("uid"), 0
objuser.PutEx ADS_PROPERTY_UPDATE, "uid", strarr
objuser.SetInfo
end if
else
objuser.Put "uid", uid
objuser.SetInfo
end if
uidNumber = ""
uidNumber = objuser.Get("uidNumber")
uidNumber = InputBox("Please Enter the value for the uidNumber value","",uidNumber)
objUser.Put "uidNumber", uidNumber
objuser.setinfo
gidNumber = ""
gidNumber = objuser.Get("gidNumber")
gidNumber = InputBox("Please Enter the value for the gidNumber value","",gidNumber)
objUser.Put "gidNumber", gidNumber
objuser.setinfo
unixHomeDirectory = ""
unixHomeDirectory = objuser.Get("unixHomeDirectory")
unixHomeDirectory = InputBox("Please Enter the value for the unixHomeDirectory value","",unixHomeDirectory)
objUser.Put "unixHomeDirectory", unixHomeDirectory
objuser.setinfo
loginShell = ""
loginShell = objuser.Get("loginShell")
loginShell = InputBox("Please Enter the value for the loginShell value","",loginShell)
objUser.Put "loginShell", loginShell
objuser.setinfo
msSFU30Name = ""
msSFU30Name = objuser.Get("msSFU30Name")
msSFU30Name = InputBox("Please Enter the value for the msSFU30Name value","",msSFU30Name)
objUser.Put "msSFU30Name", msSFU30Name
objuser.setinfo
objuser.setinfo
set objuser = nothing
objRecordSet.MoveNext
Loop
The next step is to add DNS record for the *NIX clients.
On the Microsoft Windows system, create a forward (A) and reverse (PTR) DNS record for the *NIX client. In addition, create a reverse (PTR) DNS record for the AD server. These records are required for Kerberos to function properly. The forward (A) DNS record for the Active Directory server is created automatically when configuring the Active Directory server.
We also need to Synchronizing the Clocks and Configuring Time Zones.
Time synchronization is essential for Kerberos to function properly. By default, only a 300-second clock skew is acceptable. Ensure that time zones on all Microsoft Windows and Solaris servers are configured properly. NTP can be used synchronize time.
Indexing an attribute helps queries find objects that have that attribute more quickly and efficiently than if the attribute had no index. The Active Directory directory service index is built automatically by a background thread on the directory server.
On the Microsoft Windows system, index the following *NIX client attributes: uid, uidNumber and gidNumber. In Active Directory, indexes can be added by using the Schema Management Snap-In for the Microsoft Management Console. Btw, this snap-in must be registered first.
This almost completes the steps that need to be performed on the Windows side, except one; we will mention that in appropriate time.
In our next discussions we will see how a *NIX client can be joined in active directory.
In our last discussion we talked regarding setting up password synchronization from Windows to UNIX box. Here we can add some more functionality to allow the reverse process of sending password from UNIX box back to Windows as well. This along with the earlier one; is called two way password synchronization.
To configure the UNIX to Windows password sync we need to perform all the steps that are required for Windows to UNIX password sync (discussed here); like configuring sso.conf file, copying appropriate binary to the UNIX box and adding the UNIX box name in the password sync management snap-in.
The remaining step is to copy the appropriate Pam_sso.* file from unix\bins folder to the corresponding directory and change its name. Once this is done we need to set the mode for the modified file to be 544. Finally an entry in the /etc/pam.conf (or in the related files) is required to complete the configuration.
For SFU 3.5
On HP UX: Copy pam_sso.hpx from the location to /usr/lib/security on the UNIX computer, change its name to pam_sso.hp.1, and then set its file-mode bits to 544. In /etc/pam.conf file immediately after the Password management line, add this line (before other lines): other password required /usr/lib/security/pam_sso.hp.1.
On Solaris: Copy pam_sso.sol from the location to the /usr/lib/security directory on the UNIX computer, and change its name to pam_sso.so.1. In /etc/pam.conf file immediately after the Password management line, add this line (before other lines): other password required /usr/lib/security/pam_sso.so.1.
On Linux: Copy pam_sso.rhl from the location to /lib/security on the UNIX computer, and change its name to pam_sso.so.1.On the UNIX computer, copy /etc/pam.d/system-auth to /etc/pam.d/ssod. Open /etc/pam.d/system-auth with a text editor, and locate this line: password required /lib/security/pam_cracklib.so retry=3. After this line , add the following line: password required /lib/security/pam_sso.so.1. Locate and delete the following line: password required /lib/security/pam_deny.so. Save the modified file.
In case of Windows 2003 R2:
On HP-UX: Copy pam_sso.hpx from the location to /usr/lib/security on the UNIX computer, change its name to pam_sso.hp.1, and then set its file-mode bits to 544. On the UNIX computer, open /etc/pam.conf with a text editor. In the Password management section, locate this line: other password required /usr/lib/security/libpam_unix.1. Immediately following the line located in the previous step, add the following line: other password required /usr/lib/security/pam_sso.hp.1.
On Linux:Copy pam_sso.rhl from the location to /lib/security on the UNIX computer, and change its name to pam_sso.so.1.On the UNIX computer, copy /etc/pam.d/system-auth to /etc/pam.d/ssod. Open /etc/pam.d/system-auth with a text editor, and locate the following line: passwordrequired/lib/security/pam_cracklib.soretry=3. After the line in the previous step, add the following line: password required /lib/security/pam_sso.so.1. Locate and delete this line: passwordrequired/lib/security/pam_deny.so. Save the modified file.
On Solaris: Copy pam_sso.sol from the location to the /usr/lib/security directory on the UNIX computer, and change its name to pam_sso.so.1. On the UNIX computer, open /etc/pam.conf with a text editor. In the Password management section, locate this line: other password required /usr/lib/security/$ISA/pam_unix.so.1. Immediately following this line add this line: other password required /usr/lib/security/$ISA/pam_sso.so.1.
On IBM AIX: Copy pam_sso.aix from the location to /usr/lib/ on the UNIX computer, and change its name to pam_sso.aix.1. In the Password management section, add this line: passwd password required /usr/lib/security/pam_sso.aix.1.
Also, open /usr/lib/security/methods.cfg with a text editor and add these lines at the end of the file:
PAM: program = /usr/lib/security/PAM
PAMfiles: options = auth=PAM,db=BUILTIN
Open /etc/security/user with a text editor and add authentication information for the specific users whose passwords you want to synchronize. For example:
user1: admin = false SYSTEM = PAMfiles[*] AND "compat" registry = PAMfiles
Once the appropriate file is copied any change of the password done on UNIX box will synchronize with the Windows box.
Many a times we come across scenarios where organizations need a way to ensure that a particular user logging in different operating systems (UNIX and Windows to name) and changing his password. Unless there is a mechanism in place to make that password consistent across different environment he will end up keeping multiple passwords and the end result is definitely not going to be a pleasant experience J
Identity management for UNIX (and the previous version SFU 3.5) comes with a component called Password Synchronization to address this scenario; needless to mention this component does take away a great amount of administrative overload when put in place properly. I put the word properly to echo the considerable amount of planning we need to do before we can actually put this component to work for us.
Basically we need to understand the scenarios that call for such implementation. We will be discussing the possible ways to configure password synchronization here.
In its simplest form; say we have a Windows and UNIX system and the authentication mechanism is local to the systems. The only common objects between them that we have a user (say user_wu) having same name in both the systems and needs to login in both the systems. Of course, this user does not want to remember different passwords to login to different systems; so we are looking for a way to push his password to other system when changed from another and vice-versa. And this called as two-way password sync.
Before we jump into the configurations steps; let’s list out few basic things we need to remember. The first of all is the compatibility of the components of Password Synchronization.
In case of Services for UNIX 3.5
Two-way password synchronization is supported on UNIX computers running any of the following operating systems:
· Hewlett-Packard HP-UX version 11i
· IBM AIX version 5L 5.2
· Red Hat Linux version 8.0
· Sun Microsystems Solaris versions 7 and 8 running on Scalable Processor Architecture (SPARC)–based computers
In Windows 2003 R2; the Password Synchronization that comes with Identity Management for UNIX:
Two-way password synchronization is supported on UNIX computers running any of the following operating systems:
· Hewlett-Packard HP-UX version 11i, 32-bit environment
· IBM AIX version 5L 5.2, 32-bit environment
· Red Hat Linux versions 8 and 9, 32-bit environment
· Sun Solaris version 8 running on x86-based computers and Scalable Processor Architecture (SPARC)–based computers, and Solaris version 9 running on SPARC–based computers. The 32-bit environment has been tested on SPARC-based computers.
The download link for SSOD package for Windows 2003 R2 is http://www.microsoft.com/downloads/details.aspx?FamilyID=2ba5c443-d972-4b13-81ef-8ad20f779f51&displaylang=en
In Windows 2008; the list of supported UNIX environment is some way updated:
Password Synchronization supports synchronization with UNIX computers running any of the following operating systems:
· Hewlett Packard HP UX 11i v1
· IBM® AIX® version 5L 5.2 and 5L 5.3
· SunSM Microsystems Solaris™ 10, Scalable Processor Architecture (SPARC)-compatible versions only
· Linux
o Novell® SUSE® Linux Enterprise Server 10
o Red Hat® Enterprise Linux® 4 server
The package can be downloaded from http://www.microsoft.com/downloads/details.aspx?FamilyId=8EDBE153-B4F3-4DF6-B0AD-54A43C02CA29&displaylang=en
On the Windows side; password sync component can be installed on a standalone system or on a domain controller. In case on Windows XP and Windows 2003; Password Synchronization component can be added from SFU 3.5. We need “Administrative” privilege to carry on this installation.
Let’s take a look at the configurations on the Windows side.
On SFU 3.5; the screen looks like this:
· The direction of password synchronization if one-way (Only from Windows to UNIX) or two-way (From Windows to UNIX and vice-versa)
· Encryption / Decryption key to make password human unreadable; recommendation is to change the default key
· The port no. on which a daemon will be running to capture any password replication request coming from Windows side; again the recommendation is to change the default value.
The list above mentions the essential configurations we need to care about.
On a Windows 2003 R2 box this looks almost similar; but available as properties page of Password Sync.
Now, the push the password from Windows side to Linux systems we need to perform the following steps:
Note: The steps will be some what different depending on the UNIX operating system. I will mention the parts that need to be taken care.
The unix\bins folder of different package contains the components for password synchronization. So, we need to:
Copy the appropriate source binary file from \unix\bins to /usr/bin or /usr/local/bin on the UNIX computer, and change its name to ssod. The name of the source binary file depends on the version of UNIX you are using.
If the computer is running Hewlett-Packard HP-UX, the source binary file name is ssod.hpx.
If the computer is running Red Hat Linux, the source binary file name is ssod.rhl.
If the computer is running Sun Microsystems Solaris, the source binary file name is ssod.sol.
If the computer is running IBM AIX, the source binary file name is ssod.aix.
2. Using a binary file-copy method such as File Transfer Protocol (FTP) to avoid corrupting CR/LF (carriage-return/line-feed) pairs, copy Sso.cfg from \unix\bins from the ppackage to /etc on the UNIX computer, and change its name to sso.conf.
3. Open sso.conf with a text editor.
4. If you have changed the default encryption key, edit the following line to specify the new default key. This value must match the default key specified on all domain controllers with which this computer will synchronize passwords:
ENCRYPT_KEY=encryptionKey
5. If you have changed the default port, edit the following line to specify the new port. This value must match the port number specified on all domain controllers with which this computer will synchronize passwords.
PORT_NUMBER=portNumber
6. Edit the following line to specify one domain controller in each Windows domain with which the computer is to synchronize passwords. If you have specified a nondefault port number or encryption key for the UNIX-based computer when configuring Password Synchronization on the Windows domain controllers, specify that value where indicated; otherwise, leave the value blank:
SYNC_HOSTS=(domainController[, portNumber [, encryptionKey]]) ...
Each entry in the list must be enclosed by parentheses (the "(" and ")" characters) and separated from the next entry by a blank space.
8. Set the file permissions of sso.conf to read/write for the root user only, and deny access to all other users.
9. If the computer is running Linux, copy /etc/pam.d/system-auth to /etc/pam.d/ssod; else we can skip this step.
One last step on *NIX box to start the ssod deamon using the commad: ssod –v
Back on windows side, we need to add the *NIX box in the password synchronization console:
On SFU 3.5:
On R2:
Now, we are all set the push the password from Windows box to *NIX systems; let’s reset the password for the user user_wu, and we should be able to see the events mentioning that password synchronization was done successfully to the user on the *NIX box.
In the next part we will discuss on synchronizing the password from UNIX to Windows box.
In earlier discussion we configured Windows 2003 R2 box as RSH server. It was probably the simplest configuration using hosts.equiv file.
Now we move forward again to configure Windows 2003 R2 box as RSH server; but this time using .rhosts file.
As we know that the hosts.equiv file was not useful in case of "Admin" users; .rhosts file takes care of this issue. Also, as it is kept in the home directory of the user; we have granular permission applied to this to eliminate any security issue.
Now, the actual steps:
Log in as Administrator
Create a Local or Domain user (say user1)
Modify the "Local Path" for "Home Folder" in "Profile" tab from the Property page of the user to be the Home Folder of the user
Note: RSH cannot work with .rhosts file kept in mounted Home Folder
Log in as the user (say user1)
Open C or K shell
Check the working directory - it should be the same as of the "Local Path" we put in Step 2.
Create .rhosts file
vi .rhosts
Add entry like: <IP address of the UNIX client> <User Name>
like; 192.168.1.10 User1
Save and close the file
Change the permission of the file to ensure only creator has Read and Write permission
chmod 600 .rhosts
Login again as Administrator
Restart the inet service as
cd /etc/init.d
./inet stop
./inet start
Now, let’s login from the UNIX box
For example; login as user1 on UNIX client and execute the command as:
rsh <Windows box IP or Name> <any UNIX command>
In case you are logged in as a user (other than user1) in UNIX box; modify the above command as:
rsh -l user1 <Windows box IP or Name> <any UNIX command>
Installing and configuring RSH server on Windows box has always been an area of special interest for me; especially because I have seen many issues and the troubleshooting of them has always involved unstructured steps. In this Part I; I am trying to capture the simplest possible steps that have been tested for considerable times and proved to be desirable and sufficient for such scenario. The steps mentioned below; is primarily based on Windows 2003 R2.
Once we install “Subsystem for UNIX-based applications” and “Utilities and Software Development Kit (SDK) for Subsystem for UNIX-based Applications” we can proceed for configuring RSH server on the Windows box.
On windows box:
Open C or K shell and execute the following the commands:
Move to /etc directory
cd /etc
Open a file called hosts.equiv
vi hosts.equiv
Put the entries like
<Name or IP address of the UNIX client><TAB><UserName of a UNIX user>
For example:
192.168.1.10 user1
Close and save the file
Change the permission to read only to everyone
chmod 444 /etc/hosts.equiv
Open the inetd.conf file and remove the comment entries for the following files:
shell stream tcp nowait NULL /usr/sbin/in.rshd in.rshd -a
exec stream tcp nowait NULL /usr/sbin/in.rexecd in.rexecd
login stream tcp nowait NULL /usr/sbin/in.rlogind in.rlogind -a
Save and close the file
Restart the inet service as
cd /etc/init.d
./inet stop
./inet start
We are pretty much done with the essential steps on Windows box; let’s login from the UNIX box as the user that we specified in the hosts.equiv file
For example; login as user1 from 192.168.1.10
Now execute the command as:
rsh <Windows box IP or Name> <any UNIX command> (assuming user1 is also a valid NON ADMIN user on the Windows box)
In case user1 is not a valid user on the Windows box modify the above command as:
rsh -l user1 <Windows box Ip or Name> <any UNIX command>
Note that:
hosts.equiv file only works with a NON ADMIN user
Based on my experience the following steps seem to be helpful in certain scenarios; particularly in such cases when the above mentioned steps results in “Permission denied” error.
Open windows explorer and go to C:\WINDOWS\system32\drivers\etc
Open hosts file and add the entry for the UNIX box as
<IP address of the UNIX client> <TAB><name of the UNIX box>
Save and close the file
I (actually all of us in the developer support SFU team at MS) was trying to manage some time to start writing on this blog; finally it’s time to start our journey. Hope this will be a successful initiative to express our understanding of Services for UNIX; its constant evolution. At the same time we expect to capture experiences faced by all those use this product and is looking for some or the other kind of improvement to make SFU a better one every day.
The hot fixes for SFU are now public; get the fixes right away! Look for the "Hotfix Download Available" link on the top of the KB article.
Once you are on the page following the link; it’s a two step process:
- Select hot fix
- Provide your e-mail address and submit request
By default it shows the fix available for the system you are using; versions for other platforms can be selected even by clicking on the "Select hot fix" link.
Next is to provide the e-mail address and we are done! It took around 15 minutes time to get delivered to my mail id when I tried to get one fix.
Now, the other part of the story! Not all the KB article is showing up the "Hotfix Download Available" link. But we can still get it in the same way. Use the following link and replace the "xxx" part by the KB article no.
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=xxx
For example to download KB 913030 use http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=913030.
This will take you to the page where you can follow the "two step procedure" to get the fix.
