Developer Support Services for UNIX Team

Integrating *NIX client in Active Directory using LDAP Part - II

2009-04-17T01:19:00Z

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.

Integrating *NIX client in Active Directory using LDAP Part - I

2009-04-16T21:57:00Z

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

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.

Password Synchronization between Windows and UNIX Part II

2009-04-06T20:45:00Z

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.

Password Synchronization between Windows and UNIX Part I

2009-03-06T04:01:00Z

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.

RSH on Windows 2003 R2 Part II

2008-11-11T01:33:00Z

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>

RSH on Windows 2003 R2 - Part I

2008-09-17T03:23:00Z

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

Save and close the file

Welcome to dsix : Hotfixes for SFU is now public!

2008-04-25T23:19:00Z

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.