Often times, password requirements may differ between the two system types. This means users will have to use a different password on Windows and Unix. Also, when password change dates are not synchronized between the Windows and Unix systems you’ll end with users that forget their Unix passwords on a very frequent basis.

This article is meant to provide the basic procedures to allow a Solaris system to use user information provided by Active Directory on a Windows 2008 server as the authentication method for logging into Solaris.

The following instructions are cobbled together from several locations on the internet and from in house testing.
We primarily used the following two sites, which offer steps on configuration using Windows 2003 R2. We then made changes where required.

Sun Wikis
Scott Lowe’s Blog

Our Test Environment

• Domain Controller Information
  • Windows 2008 R2
  • Hostname = win2k8-dc
  • IP Address = 192.168.3.76
  • Domain = test.sog.com
  • Kerberos Realm = TEST.SOG.COM
• Client Information
  • Solaris 10_u8 x86
  • Hostname = keystone
  • IP Address = 192.168.3.66

Windows Configuration

It is assumed that Active Directory is setup and that DNS is configured on the domain controller. The steps provided are what you need to do to add Unix functionality to an already existing Windows AD environment. The Solaris clients should be added to the DNS records on the DC.

The following steps are required to add all additional functionality to the domain controller to allow for Solaris clients to authenticate against AD.

Install UNIX Schema into Active Directory

Open “Server Manager” and click on “Roles” in the left pane. Click on “Add Role Services” in the “Active Directory Domain Services” section in the right pane.

Any users that you want to be able to use Active Directory for Solaris logins must have the Unix Attributes set under User Properties for that user. These properties include the UID, Primary GID, login shell, and home directory. (The users’ GECOS will come from the Display Name setting under the General tab of the users’ properties.)

Under Active Directory Users and Computers Right click the new user account and select Properties. In the user’s properties window select the Unix Attributes tab.

Select the domain under “NIS Domain” and fill in the fields.

All other user properties (secondary groups, RBAC roles/profiles/auths…) will come from the standard file locations on the Solaris client systems- (/etc/group, /etc/users, /etc/security/*attr)

Also, make sure that the user’s password is not set to ‘change at next login.’ Solaris does not have the hooks back into AD to do password management, so your user will not be prompted to change their password and they will not be allowed to login. All they will see is a messages saying: “Login Incorrect.”

Create Kerberos Keytab for Client System

Although this step is given on both of the sites provided above, I have found that it is not required to create a functioning Solaris -> AD authentication environment. I do not know the security implication of not performing this step.
On the Windows system, create a user account for the Solaris system that will be authenticating. In this example we are creating a user account named host-keystone for the host keystone. (Note: this is a user account, not a computer account)

Once this user is created you can disable it for security purposes.

The purpose of this step is create the keytab file that will be transferred to the /etc/krb5 directory of the Solaris system that will be authenticating against AD. In order to create the keytab file run the following command from a CMD prompt on the domain controller. (Make appropriate changes for you local environment.)

C:\Users\Administrator> ktpass –princ HOST\keystone.test.sog.com@TEST.SOG.COM -mapuser TEST\host-keystone –crypto DES-CBC-MD5 +DesOnly –pass p@ssword1 -ptype KRB5_NT_PRINCIPAL –out Desktop\keystone.keytab

Transfer the file to the host keystone as /etc/krb5/krb5.keytab

Create ProxyDN User Account

On the Windows system, create a user account that will be the proxyDN. Make this user a member of “Domain Guests.” Give it a password, and select ‘password never expires’
This will be the proxyDN username used when you run the ldapclient command later on. This account must remain enabled.
In this test we created a user account called “ProxyDNUser” with a password of “p@ssword1”

Make sure to use the Display Name under the General properties (Full Name when creating the user) during the ldapclient step. In this case the correct user to use during the ldapclient command will be ProxyDNUser. Do not use the user logon name. We ran into a bit of a problem when we kept trying to use the Windows logon name and we kept getting messages saying:

libsldap: Status: 49 Mesg: openConnection: simple bind failed – Invalid credentials

It was a bit frustrating when we were completely sure that we were using the right password and still kept getting a messages saying ‘Invalid Credentials.’

Use ADSIedit on your domain controller to see the full DN for the user account if you keep getting the message above and you’re positive you have the password correct.

Solaris Configuration

Client Side DNS Configuration

Your Solaris system should be a member of the DNS domain defined by your domain controller. Make sure to create both forward and reverse lookup records in the domain for the Solaris system.

# cat /etc/resolv.conf
domain test.sog.com
nameserver 192.168.3.76

Make sure you have the /etc/nsswitch.conf file setup to use DNS as a name service for hosts.

# grep ‘^hosts’ /etc/nsswitch.conf
hosts files dns

Verify that DNS works.

# nslookup `hostname`
Server: 192.168.3.76
Address: 192.168.3.76#53

Name: keystone.test.sog.com
Address: 192.168.3.66

The following nslookup commands should produce output similar to the following.

# nslookup -querytype=any _ldap._tcp
Server: 192.168.3.76
Address: 192.168.3.76#53

_ldap._tcp.test.sog.com service = 0 100 389 win2k8-dc.test.sog.com.

# nslookup -querytype=any _gc._tcp
Server: 192.168.3.76
Address: 192.168.3.76#53

_gc._tcp.test.sog.com service = 0 100 3268 win2k8-dc.test.sog.com.

Kerberos

Configure the /etc/krb5/krb5.conf file on the Solaris client. Make appropriate changes required for your local environment.
This is the /etc/krb5/krb5.conf that we used on our test system.

[libdefaults]
default_realm = TEST.SOG.COM
dns_lookup_kdc = true
verify_ap_req_nofail = false
[realms]
TEST.SOG.COM = {
kdc = WIN2K8-DC.TEST.SOG.COM
default_domain = TEST
admin_server = WIN2K8-DC.TEST.SOG.COM
}
[domain_realm]
.test.sog.com = TEST.SOG.COM
test.sog.com = TEST.SOG.COM
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {
period = 1d
versions = 10
}
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
kinit = {
renewable = true
forwardable= true
}

Run the kinit command and enter the administrator’s password. If the command runs successfully, you will see no output.

# kinit administrator
Password for administrator@TEST.SOG.COM:

LDAP

ldap client initialization on Solaris host. The part of the command in orange needs to be modified for your environment. The rest of the command is standard across all configurations.

# ldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN=cn=”ProxyDNUser,cn=Users,dc=TEST,dc=SOG,dc=COM” \
-a proxyPassword=p@ssword1 \
-a defaultSearchBase=dc=TEST,dc=SOG,dc=COM \
-a domainName=TEST.SOG.COM \
-a “defaultServerList=192.168.3.76″ \
-a attributeMap=group:userpassword=userPassword \
-a attributeMap=group:memberuid=memberUid \
-a attributeMap=group:gidnumber=gidNumber \
-a attributeMap=passwd:gecos=cn \
-a attributeMap=passwd:gidnumber=gidNumber \
-a attributeMap=passwd:uidnumber=uidNumber \
-a attributeMap=passwd:homedirectory=unixHomeDirectory \
-a attributeMap=passwd:loginshell=loginShell \
-a attributeMap=shadow:shadowflag=shadowFlag \
-a attributeMap=shadow:userpassword=userPassword \
-a objectClassMap=group:posixGroup=group \
-a objectClassMap=passwd:posixAccount=user \
-a objectClassMap=shadow:shadowAccount=user \
-a serviceSearchDescriptor=passwd:dc=TEST,dc=SOG,dc=COM?sub \
-a serviceSearchDescriptor=group:dc=TEST,dc=SOG,dc=COM?sub

# cp /etc/nsswitch.files /etc/nsswitch.conf

# vi /etc/nsswitch.conf
passwd files ldap
group files ldap
hosts files dns

# svcadm restart ldap/client

PAM

Edit /etc/pam.conf to use Kerberos authentication. Both sites provided at the top of this article show the same modifications to pam.conf. In our tests we found that those entries caused problems, most notably that the root user could not login from the console. Here is the /etc/pam.conf that we found to work best.

# vi /etc/pam.conf
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
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
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
#
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
# Default definition for Password management
# Used when service name is not explicitly mentioned for password management
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

Create home directory for user.

# mkdir -p /export/home/john.doe
# chown john.doe:staff /export/home/john.doe
# chmod 700 /export/home/john.doe

You should now be able to log into your Solaris system with your AD user account.

ABOUT US
Seeds of Genius, Inc. offers a full range of IT solutions including hardware and software products in addition to consulting, installation and support services. For more information, please visit our main web site at http://www.seedsofgenius.com or contact our Technical Sales department at (410) 312-9806.

Often times, password requirements may differ between the two system types. This means users will have to use a different password on Windows and Unix. Also, when password change dates are not synchronized between the Windows and Unix systems you’ll end with users that forget their Unix passwords on a very frequent basis.

This article is meant to provide the basic procedures to allow a Solaris system to use user information provided by Active Directory on a Windows 2008 server as the authentication method for logging into Solaris.

The following instructions are cobbled together from several locations on the internet and from in house testing.
We primarily used the following two sites, which offer steps on configuration using Windows 2003 R2. We then made changes where required.

Sun Wikis
Scott Lowe’s Blog

Our Test Environment

• Domain Controller Information
  • Windows 2008 R2
  • Hostname = win2k8-dc
  • IP Address = 192.168.3.76
  • Domain = test.sog.com
  • Kerberos Realm = TEST.SOG.COM
• Client Information
  • Solaris 10_u8 x86
  • Hostname = keystone
  • IP Address = 192.168.3.66

Windows Configuration

It is assumed that Active Directory is setup and that DNS is configured on the domain controller. The steps provided are what you need to do to add Unix functionality to an already existing Windows AD environment. The Solaris clients should be added to the DNS records on the DC.

The following steps are required to add all additional functionality to the domain controller to allow for Solaris clients to authenticate against AD.

Install UNIX Schema into Active Directory

Open “Server Manager” and click on “Roles” in the left pane. Click on “Add Role Services” in the “Active Directory Domain Services” section in the right pane.

Any users that you want to be able to use Active Directory for Solaris logins must have the Unix Attributes set under User Properties for that user. These properties include the UID, Primary GID, login shell, and home directory. (The users’ GECOS will come from the Display Name setting under the General tab of the users’ properties.)

Under Active Directory Users and Computers Right click the new user account and select Properties. In the user’s properties window select the Unix Attributes tab.

Select the domain under “NIS Domain” and fill in the fields.

All other user properties (secondary groups, RBAC roles/profiles/auths…) will come from the standard file locations on the Solaris client systems- (/etc/group, /etc/users, /etc/security/*attr)

Also, make sure that the user’s password is not set to ‘change at next login.’ Solaris does not have the hooks back into AD to do password management, so your user will not be prompted to change their password and they will not be allowed to login. All they will see is a messages saying: “Login Incorrect.”

Create Kerberos Keytab for Client System

Although this step is given on both of the sites provided above, I have found that it is not required to create a functioning Solaris -> AD authentication environment. I do not know the security implication of not performing this step.
On the Windows system, create a user account for the Solaris system that will be authenticating. In this example we are creating a user account named host-keystone for the host keystone. (Note: this is a user account, not a computer account)

Once this user is created you can disable it for security purposes.

The purpose of this step is create the keytab file that will be transferred to the /etc/krb5 directory of the Solaris system that will be authenticating against AD. In order to create the keytab file run the following command from a CMD prompt on the domain controller. (Make appropriate changes for you local environment.)

C:\Users\Administrator> ktpass –princ HOST\keystone.test.sog.com@TEST.SOG.COM -mapuser TEST\host-keystone –crypto DES-CBC-MD5 +DesOnly –pass p@ssword1 -ptype KRB5_NT_PRINCIPAL –out Desktop\keystone.keytab

Transfer the file to the host keystone as /etc/krb5/krb5.keytab

Create ProxyDN User Account

On the Windows system, create a user account that will be the proxyDN. Make this user a member of “Domain Guests.” Give it a password, and select ‘password never expires’
This will be the proxyDN username used when you run the ldapclient command later on. This account must remain enabled.
In this test we created a user account called “ProxyDNUser” with a password of “p@ssword1”

Make sure to use the Display Name under the General properties (Full Name when creating the user) during the ldapclient step. In this case the correct user to use during the ldapclient command will be ProxyDNUser. Do not use the user logon name. We ran into a bit of a problem when we kept trying to use the Windows logon name and we kept getting messages saying:

libsldap: Status: 49 Mesg: openConnection: simple bind failed – Invalid credentials

It was a bit frustrating when we were completely sure that we were using the right password and still kept getting a messages saying ‘Invalid Credentials.’

Use ADSIedit on your domain controller to see the full DN for the user account if you keep getting the message above and you’re positive you have the password correct.

Solaris Configuration

Client Side DNS Configuration

Your Solaris system should be a member of the DNS domain defined by your domain controller. Make sure to create both forward and reverse lookup records in the domain for the Solaris system.

# cat /etc/resolv.conf
domain test.sog.com
nameserver 192.168.3.76

Make sure you have the /etc/nsswitch.conf file setup to use DNS as a name service for hosts.

# grep ‘^hosts’ /etc/nsswitch.conf
hosts files dns

Verify that DNS works.

# nslookup `hostname`
Server: 192.168.3.76
Address: 192.168.3.76#53

Name: keystone.test.sog.com
Address: 192.168.3.66

The following nslookup commands should produce output similar to the following.

# nslookup -querytype=any _ldap._tcp
Server: 192.168.3.76
Address: 192.168.3.76#53

_ldap._tcp.test.sog.com service = 0 100 389 win2k8-dc.test.sog.com.

# nslookup -querytype=any _gc._tcp
Server: 192.168.3.76
Address: 192.168.3.76#53

_gc._tcp.test.sog.com service = 0 100 3268 win2k8-dc.test.sog.com.

Kerberos

Configure the /etc/krb5/krb5.conf file on the Solaris client. Make appropriate changes required for your local environment.
This is the /etc/krb5/krb5.conf that we used on our test system.

[libdefaults]
default_realm = TEST.SOG.COM
dns_lookup_kdc = true
verify_ap_req_nofail = false
[realms]
TEST.SOG.COM = {
kdc = WIN2K8-DC.TEST.SOG.COM
default_domain = TEST
admin_server = WIN2K8-DC.TEST.SOG.COM
}
[domain_realm]
.test.sog.com = TEST.SOG.COM
test.sog.com = TEST.SOG.COM
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {
period = 1d
versions = 10
}
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
kinit = {
renewable = true
forwardable= true
}

Run the kinit command and enter the administrator’s password. If the command runs successfully, you will see no output.

# kinit administrator
Password for administrator@TEST.SOG.COM:

LDAP

ldap client initialization on Solaris host. The part of the command in orange needs to be modified for your environment. The rest of the command is standard across all configurations.

# ldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN=cn=”ProxyDNUser,cn=Users,dc=TEST,dc=SOG,dc=COM” \
-a proxyPassword=p@ssword1 \
-a defaultSearchBase=dc=TEST,dc=SOG,dc=COM \
-a domainName=TEST.SOG.COM \
-a “defaultServerList=192.168.3.76″ \
-a attributeMap=group:userpassword=userPassword \
-a attributeMap=group:memberuid=memberUid \
-a attributeMap=group:gidnumber=gidNumber \
-a attributeMap=passwd:gecos=cn \
-a attributeMap=passwd:gidnumber=gidNumber \
-a attributeMap=passwd:uidnumber=uidNumber \
-a attributeMap=passwd:homedirectory=unixHomeDirectory \
-a attributeMap=passwd:loginshell=loginShell \
-a attributeMap=shadow:shadowflag=shadowFlag \
-a attributeMap=shadow:userpassword=userPassword \
-a objectClassMap=group:posixGroup=group \
-a objectClassMap=passwd:posixAccount=user \
-a objectClassMap=shadow:shadowAccount=user \
-a serviceSearchDescriptor=passwd:dc=TEST,dc=SOG,dc=COM?sub \
-a serviceSearchDescriptor=group:dc=TEST,dc=SOG,dc=COM?sub

# cp /etc/nsswitch.files /etc/nsswitch.conf

# vi /etc/nsswitch.conf
passwd files ldap
group files ldap
hosts files dns

# svcadm restart ldap/client

PAM

Edit /etc/pam.conf to use Kerberos authentication. Both sites provided at the top of this article show the same modifications to pam.conf. In our tests we found that those entries caused problems, most notably that the root user could not login from the console. Here is the /etc/pam.conf that we found to work best.

# vi /etc/pam.conf
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
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
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
#
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
# Default definition for Password management
# Used when service name is not explicitly mentioned for password management
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

Create home directory for user.

# mkdir -p /export/home/john.doe
# chown john.doe:staff /export/home/john.doe
# chmod 700 /export/home/john.doe

You should now be able to log into your Solaris system with your AD user account.

ABOUT US
Seeds of Genius, Inc. offers a full range of IT solutions including hardware and software products in addition to consulting, installation and support services. For more information, please visit our main web site at http://www.seedsofgenius.com or contact our Technical Sales department at (410) 312-9806.

Often times, password requirements may differ between the two system types. This means users will have to use a different password on Windows and Unix. Also, when password change dates are not synchronized between the Windows and Unix systems you’ll end with users that forget their Unix passwords on a very frequent basis.

This article is meant to provide the basic procedures to allow a Solaris system to use user information provided by Active Directory on a Windows 2008 server as the authentication method for logging into Solaris.

The following instructions are cobbled together from several locations on the internet and from in house testing.
We primarily used the following two sites, which offer steps on configuration using Windows 2003 R2. We then made changes where required.

Sun Wikis
Scott Lowe’s Blog

Our Test Environment

• Domain Controller Information
  • Windows 2008 R2
  • Hostname = win2k8-dc
  • IP Address = 192.168.3.76
  • Domain = test.sog.com
  • Kerberos Realm = TEST.SOG.COM
• Client Information
  • Solaris 10_u8 x86
  • Hostname = keystone
  • IP Address = 192.168.3.66

Windows Configuration

It is assumed that Active Directory is setup and that DNS is configured on the domain controller. The steps provided are what you need to do to add Unix functionality to an already existing Windows AD environment. The Solaris clients should be added to the DNS records on the DC.

The following steps are required to add all additional functionality to the domain controller to allow for Solaris clients to authenticate against AD.

Install UNIX Schema into Active Directory

Open “Server Manager” and click on “Roles” in the left pane. Click on “Add Role Services” in the “Active Directory Domain Services” section in the right pane.

Any users that you want to be able to use Active Directory for Solaris logins must have the Unix Attributes set under User Properties for that user. These properties include the UID, Primary GID, login shell, and home directory. (The users’ GECOS will come from the Display Name setting under the General tab of the users’ properties.)

Under Active Directory Users and Computers Right click the new user account and select Properties. In the user’s properties window select the Unix Attributes tab.

Select the domain under “NIS Domain” and fill in the fields.

All other user properties (secondary groups, RBAC roles/profiles/auths…) will come from the standard file locations on the Solaris client systems- (/etc/group, /etc/users, /etc/security/*attr)

Also, make sure that the user’s password is not set to ‘change at next login.’ Solaris does not have the hooks back into AD to do password management, so your user will not be prompted to change their password and they will not be allowed to login. All they will see is a messages saying: “Login Incorrect.”

Create Kerberos Keytab for Client System

Although this step is given on both of the sites provided above, I have found that it is not required to create a functioning Solaris -> AD authentication environment. I do not know the security implication of not performing this step.
On the Windows system, create a user account for the Solaris system that will be authenticating. In this example we are creating a user account named host-keystone for the host keystone. (Note: this is a user account, not a computer account)

Once this user is created you can disable it for security purposes.

The purpose of this step is create the keytab file that will be transferred to the /etc/krb5 directory of the Solaris system that will be authenticating against AD. In order to create the keytab file run the following command from a CMD prompt on the domain controller. (Make appropriate changes for you local environment.)

C:\Users\Administrator> ktpass –princ HOST\keystone.test.sog.com@TEST.SOG.COM -mapuser TEST\host-keystone –crypto DES-CBC-MD5 +DesOnly –pass p@ssword1 -ptype KRB5_NT_PRINCIPAL –out Desktop\keystone.keytab

Transfer the file to the host keystone as /etc/krb5/krb5.keytab

Create ProxyDN User Account

On the Windows system, create a user account that will be the proxyDN. Make this user a member of “Domain Guests.” Give it a password, and select ‘password never expires’
This will be the proxyDN username used when you run the ldapclient command later on. This account must remain enabled.
In this test we created a user account called “ProxyDNUser” with a password of “p@ssword1”

Make sure to use the Display Name under the General properties (Full Name when creating the user) during the ldapclient step. In this case the correct user to use during the ldapclient command will be ProxyDNUser. Do not use the user logon name. We ran into a bit of a problem when we kept trying to use the Windows logon name and we kept getting messages saying:

libsldap: Status: 49 Mesg: openConnection: simple bind failed – Invalid credentials

It was a bit frustrating when we were completely sure that we were using the right password and still kept getting a messages saying ‘Invalid Credentials.’

Use ADSIedit on your domain controller to see the full DN for the user account if you keep getting the message above and you’re positive you have the password correct.

Solaris Configuration

Client Side DNS Configuration

Your Solaris system should be a member of the DNS domain defined by your domain controller. Make sure to create both forward and reverse lookup records in the domain for the Solaris system.

# cat /etc/resolv.conf
domain test.sog.com
nameserver 192.168.3.76

Make sure you have the /etc/nsswitch.conf file setup to use DNS as a name service for hosts.

# grep ‘^hosts’ /etc/nsswitch.conf
hosts files dns

Verify that DNS works.

# nslookup `hostname`
Server: 192.168.3.76
Address: 192.168.3.76#53

Name: keystone.test.sog.com
Address: 192.168.3.66

The following nslookup commands should produce output similar to the following.

# nslookup -querytype=any _ldap._tcp
Server: 192.168.3.76
Address: 192.168.3.76#53

_ldap._tcp.test.sog.com service = 0 100 389 win2k8-dc.test.sog.com.

# nslookup -querytype=any _gc._tcp
Server: 192.168.3.76
Address: 192.168.3.76#53

_gc._tcp.test.sog.com service = 0 100 3268 win2k8-dc.test.sog.com.

Kerberos

Configure the /etc/krb5/krb5.conf file on the Solaris client. Make appropriate changes required for your local environment.
This is the /etc/krb5/krb5.conf that we used on our test system.

[libdefaults]
default_realm = TEST.SOG.COM
dns_lookup_kdc = true
verify_ap_req_nofail = false
[realms]
TEST.SOG.COM = {
kdc = WIN2K8-DC.TEST.SOG.COM
default_domain = TEST
admin_server = WIN2K8-DC.TEST.SOG.COM
}
[domain_realm]
.test.sog.com = TEST.SOG.COM
test.sog.com = TEST.SOG.COM
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {
period = 1d
versions = 10
}
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
kinit = {
renewable = true
forwardable= true
}

Run the kinit command and enter the administrator’s password. If the command runs successfully, you will see no output.

# kinit administrator
Password for administrator@TEST.SOG.COM:

LDAP

ldap client initialization on Solaris host. The part of the command in orange needs to be modified for your environment. The rest of the command is standard across all configurations.

# ldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN=cn=”ProxyDNUser,cn=Users,dc=TEST,dc=SOG,dc=COM” \
-a proxyPassword=p@ssword1 \
-a defaultSearchBase=dc=TEST,dc=SOG,dc=COM \
-a domainName=TEST.SOG.COM \
-a “defaultServerList=192.168.3.76″ \
-a attributeMap=group:userpassword=userPassword \
-a attributeMap=group:memberuid=memberUid \
-a attributeMap=group:gidnumber=gidNumber \
-a attributeMap=passwd:gecos=cn \
-a attributeMap=passwd:gidnumber=gidNumber \
-a attributeMap=passwd:uidnumber=uidNumber \
-a attributeMap=passwd:homedirectory=unixHomeDirectory \
-a attributeMap=passwd:loginshell=loginShell \
-a attributeMap=shadow:shadowflag=shadowFlag \
-a attributeMap=shadow:userpassword=userPassword \
-a objectClassMap=group:posixGroup=group \
-a objectClassMap=passwd:posixAccount=user \
-a objectClassMap=shadow:shadowAccount=user \
-a serviceSearchDescriptor=passwd:dc=TEST,dc=SOG,dc=COM?sub \
-a serviceSearchDescriptor=group:dc=TEST,dc=SOG,dc=COM?sub

# cp /etc/nsswitch.files /etc/nsswitch.conf

# vi /etc/nsswitch.conf
passwd files ldap
group files ldap
hosts files dns

# svcadm restart ldap/client

PAM

Edit /etc/pam.conf to use Kerberos authentication. Both sites provided at the top of this article show the same modifications to pam.conf. In our tests we found that those entries caused problems, most notably that the root user could not login from the console. Here is the /etc/pam.conf that we found to work best.

# vi /etc/pam.conf
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
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
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
#
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
# Default definition for Password management
# Used when service name is not explicitly mentioned for password management
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

Create home directory for user.

# mkdir -p /export/home/john.doe
# chown john.doe:staff /export/home/john.doe
# chmod 700 /export/home/john.doe

You should now be able to log into your Solaris system with your AD user account.

ABOUT US
Seeds of Genius, Inc. offers a full range of IT solutions including hardware and software products in addition to consulting, installation and support services. For more information, please visit our main web site at http://www.seedsofgenius.com or contact our Technical Sales department at (410) 312-9806.

Often times, password requirements may differ between the two system types. This means users will have to use a different password on Windows and Unix. Also, when password change dates are not synchronized between the Windows and Unix systems you’ll end with users that forget their Unix passwords on a very frequent basis.

This article is meant to provide the basic procedures to allow a Solaris system to use user information provided by Active Directory on a Windows 2008 server as the authentication method for logging into Solaris.

The following instructions are cobbled together from several locations on the internet and from in house testing.
We primarily used the following two sites, which offer steps on configuration using Windows 2003 R2. We then made changes where required.

Sun Wikis
Scott Lowe’s Blog

Our Test Environment

• Domain Controller Information
  • Windows 2008 R2
  • Hostname = win2k8-dc
  • IP Address = 192.168.3.76
  • Domain = test.sog.com
  • Kerberos Realm = TEST.SOG.COM
• Client Information
  • Solaris 10_u8 x86
  • Hostname = keystone
  • IP Address = 192.168.3.66

Windows Configuration

It is assumed that Active Directory is setup and that DNS is configured on the domain controller. The steps provided are what you need to do to add Unix functionality to an already existing Windows AD environment. The Solaris clients should be added to the DNS records on the DC.

The following steps are required to add all additional functionality to the domain controller to allow for Solaris clients to authenticate against AD.

Install UNIX Schema into Active Directory

Open “Server Manager” and click on “Roles” in the left pane. Click on “Add Role Services” in the “Active Directory Domain Services” section in the right pane.

Any users that you want to be able to use Active Directory for Solaris logins must have the Unix Attributes set under User Properties for that user. These properties include the UID, Primary GID, login shell, and home directory. (The users’ GECOS will come from the Display Name setting under the General tab of the users’ properties.)

Under Active Directory Users and Computers Right click the new user account and select Properties. In the user’s properties window select the Unix Attributes tab.

Select the domain under “NIS Domain” and fill in the fields.

All other user properties (secondary groups, RBAC roles/profiles/auths…) will come from the standard file locations on the Solaris client systems- (/etc/group, /etc/users, /etc/security/*attr)

Also, make sure that the user’s password is not set to ‘change at next login.’ Solaris does not have the hooks back into AD to do password management, so your user will not be prompted to change their password and they will not be allowed to login. All they will see is a messages saying: “Login Incorrect.”

Create Kerberos Keytab for Client System

Although this step is given on both of the sites provided above, I have found that it is not required to create a functioning Solaris -> AD authentication environment. I do not know the security implication of not performing this step.
On the Windows system, create a user account for the Solaris system that will be authenticating. In this example we are creating a user account named host-keystone for the host keystone. (Note: this is a user account, not a computer account)

Once this user is created you can disable it for security purposes.

The purpose of this step is create the keytab file that will be transferred to the /etc/krb5 directory of the Solaris system that will be authenticating against AD. In order to create the keytab file run the following command from a CMD prompt on the domain controller. (Make appropriate changes for you local environment.)

C:\Users\Administrator> ktpass –princ HOST\keystone.test.sog.com@TEST.SOG.COM -mapuser TEST\host-keystone –crypto DES-CBC-MD5 +DesOnly –pass p@ssword1 -ptype KRB5_NT_PRINCIPAL –out Desktop\keystone.keytab

Transfer the file to the host keystone as /etc/krb5/krb5.keytab

Create ProxyDN User Account

On the Windows system, create a user account that will be the proxyDN. Make this user a member of “Domain Guests.” Give it a password, and select ‘password never expires’
This will be the proxyDN username used when you run the ldapclient command later on. This account must remain enabled.
In this test we created a user account called “ProxyDNUser” with a password of “p@ssword1”

Make sure to use the Display Name under the General properties (Full Name when creating the user) during the ldapclient step. In this case the correct user to use during the ldapclient command will be ProxyDNUser. Do not use the user logon name. We ran into a bit of a problem when we kept trying to use the Windows logon name and we kept getting messages saying:

libsldap: Status: 49 Mesg: openConnection: simple bind failed – Invalid credentials

It was a bit frustrating when we were completely sure that we were using the right password and still kept getting a messages saying ‘Invalid Credentials.’

Use ADSIedit on your domain controller to see the full DN for the user account if you keep getting the message above and you’re positive you have the password correct.

Solaris Configuration

Client Side DNS Configuration

Your Solaris system should be a member of the DNS domain defined by your domain controller. Make sure to create both forward and reverse lookup records in the domain for the Solaris system.

# cat /etc/resolv.conf
domain test.sog.com
nameserver 192.168.3.76

Make sure you have the /etc/nsswitch.conf file setup to use DNS as a name service for hosts.

# grep ‘^hosts’ /etc/nsswitch.conf
hosts files dns

Verify that DNS works.

# nslookup `hostname`
Server: 192.168.3.76
Address: 192.168.3.76#53

Name: keystone.test.sog.com
Address: 192.168.3.66

The following nslookup commands should produce output similar to the following.

# nslookup -querytype=any _ldap._tcp
Server: 192.168.3.76
Address: 192.168.3.76#53

_ldap._tcp.test.sog.com service = 0 100 389 win2k8-dc.test.sog.com.

# nslookup -querytype=any _gc._tcp
Server: 192.168.3.76
Address: 192.168.3.76#53

_gc._tcp.test.sog.com service = 0 100 3268 win2k8-dc.test.sog.com.

Kerberos

Configure the /etc/krb5/krb5.conf file on the Solaris client. Make appropriate changes required for your local environment.
This is the /etc/krb5/krb5.conf that we used on our test system.

[libdefaults]
default_realm = TEST.SOG.COM
dns_lookup_kdc = true
verify_ap_req_nofail = false
[realms]
TEST.SOG.COM = {
kdc = WIN2K8-DC.TEST.SOG.COM
default_domain = TEST
admin_server = WIN2K8-DC.TEST.SOG.COM
}
[domain_realm]
.test.sog.com = TEST.SOG.COM
test.sog.com = TEST.SOG.COM
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {
period = 1d
versions = 10
}
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
kinit = {
renewable = true
forwardable= true
}

Run the kinit command and enter the administrator’s password. If the command runs successfully, you will see no output.

# kinit administrator
Password for administrator@TEST.SOG.COM:

LDAP

ldap client initialization on Solaris host. The part of the command in orange needs to be modified for your environment. The rest of the command is standard across all configurations.

# ldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN=cn=”ProxyDNUser,cn=Users,dc=TEST,dc=SOG,dc=COM” \
-a proxyPassword=p@ssword1 \
-a defaultSearchBase=dc=TEST,dc=SOG,dc=COM \
-a domainName=TEST.SOG.COM \
-a “defaultServerList=192.168.3.76″ \
-a attributeMap=group:userpassword=userPassword \
-a attributeMap=group:memberuid=memberUid \
-a attributeMap=group:gidnumber=gidNumber \
-a attributeMap=passwd:gecos=cn \
-a attributeMap=passwd:gidnumber=gidNumber \
-a attributeMap=passwd:uidnumber=uidNumber \
-a attributeMap=passwd:homedirectory=unixHomeDirectory \
-a attributeMap=passwd:loginshell=loginShell \
-a attributeMap=shadow:shadowflag=shadowFlag \
-a attributeMap=shadow:userpassword=userPassword \
-a objectClassMap=group:posixGroup=group \
-a objectClassMap=passwd:posixAccount=user \
-a objectClassMap=shadow:shadowAccount=user \
-a serviceSearchDescriptor=passwd:dc=TEST,dc=SOG,dc=COM?sub \
-a serviceSearchDescriptor=group:dc=TEST,dc=SOG,dc=COM?sub

# cp /etc/nsswitch.files /etc/nsswitch.conf

# vi /etc/nsswitch.conf
passwd files ldap
group files ldap
hosts files dns

# svcadm restart ldap/client

PAM

Edit /etc/pam.conf to use Kerberos authentication. Both sites provided at the top of this article show the same modifications to pam.conf. In our tests we found that those entries caused problems, most notably that the root user could not login from the console. Here is the /etc/pam.conf that we found to work best.

# vi /etc/pam.conf
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
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
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
#
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
# Default definition for Password management
# Used when service name is not explicitly mentioned for password management
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

Create home directory for user.

# mkdir -p /export/home/john.doe
# chown john.doe:staff /export/home/john.doe
# chmod 700 /export/home/john.doe

You should now be able to log into your Solaris system with your AD user account.

ABOUT US
Seeds of Genius, Inc. offers a full range of IT solutions including hardware and software products in addition to consulting, installation and support services. For more information, please visit our main web site at http://www.seedsofgenius.com or contact our Technical Sales department at (410) 312-9806.

Often times, password requirements may differ between the two system types. This means users will have to use a different password on Windows and Unix. Also, when password change dates are not synchronized between the Windows and Unix systems you’ll end with users that forget their Unix passwords on a very frequent basis.

This article is meant to provide the basic procedures to allow a Solaris system to use user information provided by Active Directory on a Windows 2008 server as the authentication method for logging into Solaris.

The following instructions are cobbled together from several locations on the internet and from in house testing.
We primarily used the following two sites, which offer steps on configuration using Windows 2003 R2. We then made changes where required.

Sun Wikis
Scott Lowe’s Blog

Our Test Environment

• Domain Controller Information
  • Windows 2008 R2
  • Hostname = win2k8-dc
  • IP Address = 192.168.3.76
  • Domain = test.sog.com
  • Kerberos Realm = TEST.SOG.COM
• Client Information
  • Solaris 10_u8 x86
  • Hostname = keystone
  • IP Address = 192.168.3.66

Windows Configuration

It is assumed that Active Directory is setup and that DNS is configured on the domain controller. The steps provided are what you need to do to add Unix functionality to an already existing Windows AD environment. The Solaris clients should be added to the DNS records on the DC.

The following steps are required to add all additional functionality to the domain controller to allow for Solaris clients to authenticate against AD.

Install UNIX Schema into Active Directory

Open “Server Manager” and click on “Roles” in the left pane. Click on “Add Role Services” in the “Active Directory Domain Services” section in the right pane.

Any users that you want to be able to use Active Directory for Solaris logins must have the Unix Attributes set under User Properties for that user. These properties include the UID, Primary GID, login shell, and home directory. (The users’ GECOS will come from the Display Name setting under the General tab of the users’ properties.)

Under Active Directory Users and Computers Right click the new user account and select Properties. In the user’s properties window select the Unix Attributes tab.

Select the domain under “NIS Domain” and fill in the fields.

All other user properties (secondary groups, RBAC roles/profiles/auths…) will come from the standard file locations on the Solaris client systems- (/etc/group, /etc/users, /etc/security/*attr)

Also, make sure that the user’s password is not set to ‘change at next login.’ Solaris does not have the hooks back into AD to do password management, so your user will not be prompted to change their password and they will not be allowed to login. All they will see is a messages saying: “Login Incorrect.”

Create Kerberos Keytab for Client System

Although this step is given on both of the sites provided above, I have found that it is not required to create a functioning Solaris -> AD authentication environment. I do not know the security implication of not performing this step.
On the Windows system, create a user account for the Solaris system that will be authenticating. In this example we are creating a user account named host-keystone for the host keystone. (Note: this is a user account, not a computer account)

Once this user is created you can disable it for security purposes.

The purpose of this step is create the keytab file that will be transferred to the /etc/krb5 directory of the Solaris system that will be authenticating against AD. In order to create the keytab file run the following command from a CMD prompt on the domain controller. (Make appropriate changes for you local environment.)

C:\Users\Administrator> ktpass –princ HOST\keystone.test.sog.com@TEST.SOG.COM -mapuser TEST\host-keystone –crypto DES-CBC-MD5 +DesOnly –pass p@ssword1 -ptype KRB5_NT_PRINCIPAL –out Desktop\keystone.keytab

Transfer the file to the host keystone as /etc/krb5/krb5.keytab

Create ProxyDN User Account

On the Windows system, create a user account that will be the proxyDN. Make this user a member of “Domain Guests.” Give it a password, and select ‘password never expires’
This will be the proxyDN username used when you run the ldapclient command later on. This account must remain enabled.
In this test we created a user account called “ProxyDNUser” with a password of “p@ssword1”

Make sure to use the Display Name under the General properties (Full Name when creating the user) during the ldapclient step. In this case the correct user to use during the ldapclient command will be ProxyDNUser. Do not use the user logon name. We ran into a bit of a problem when we kept trying to use the Windows logon name and we kept getting messages saying:

libsldap: Status: 49 Mesg: openConnection: simple bind failed – Invalid credentials

It was a bit frustrating when we were completely sure that we were using the right password and still kept getting a messages saying ‘Invalid Credentials.’

Use ADSIedit on your domain controller to see the full DN for the user account if you keep getting the message above and you’re positive you have the password correct.

Solaris Configuration

Client Side DNS Configuration

Your Solaris system should be a member of the DNS domain defined by your domain controller. Make sure to create both forward and reverse lookup records in the domain for the Solaris system.

# cat /etc/resolv.conf
domain test.sog.com
nameserver 192.168.3.76

Make sure you have the /etc/nsswitch.conf file setup to use DNS as a name service for hosts.

# grep ‘^hosts’ /etc/nsswitch.conf
hosts files dns

Verify that DNS works.

# nslookup `hostname`
Server: 192.168.3.76
Address: 192.168.3.76#53

Name: keystone.test.sog.com
Address: 192.168.3.66

The following nslookup commands should produce output similar to the following.

# nslookup -querytype=any _ldap._tcp
Server: 192.168.3.76
Address: 192.168.3.76#53

_ldap._tcp.test.sog.com service = 0 100 389 win2k8-dc.test.sog.com.

# nslookup -querytype=any _gc._tcp
Server: 192.168.3.76
Address: 192.168.3.76#53

_gc._tcp.test.sog.com service = 0 100 3268 win2k8-dc.test.sog.com.

Kerberos

Configure the /etc/krb5/krb5.conf file on the Solaris client. Make appropriate changes required for your local environment.
This is the /etc/krb5/krb5.conf that we used on our test system.

[libdefaults]
default_realm = TEST.SOG.COM
dns_lookup_kdc = true
verify_ap_req_nofail = false
[realms]
TEST.SOG.COM = {
kdc = WIN2K8-DC.TEST.SOG.COM
default_domain = TEST
admin_server = WIN2K8-DC.TEST.SOG.COM
}
[domain_realm]
.test.sog.com = TEST.SOG.COM
test.sog.com = TEST.SOG.COM
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {
period = 1d
versions = 10
}
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
kinit = {
renewable = true
forwardable= true
}

Run the kinit command and enter the administrator’s password. If the command runs successfully, you will see no output.

# kinit administrator
Password for administrator@TEST.SOG.COM:

LDAP

ldap client initialization on Solaris host. The part of the command in orange needs to be modified for your environment. The rest of the command is standard across all configurations.

# ldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN=cn=”ProxyDNUser,cn=Users,dc=TEST,dc=SOG,dc=COM” \
-a proxyPassword=p@ssword1 \
-a defaultSearchBase=dc=TEST,dc=SOG,dc=COM \
-a domainName=TEST.SOG.COM \
-a “defaultServerList=192.168.3.76″ \
-a attributeMap=group:userpassword=userPassword \
-a attributeMap=group:memberuid=memberUid \
-a attributeMap=group:gidnumber=gidNumber \
-a attributeMap=passwd:gecos=cn \
-a attributeMap=passwd:gidnumber=gidNumber \
-a attributeMap=passwd:uidnumber=uidNumber \
-a attributeMap=passwd:homedirectory=unixHomeDirectory \
-a attributeMap=passwd:loginshell=loginShell \
-a attributeMap=shadow:shadowflag=shadowFlag \
-a attributeMap=shadow:userpassword=userPassword \
-a objectClassMap=group:posixGroup=group \
-a objectClassMap=passwd:posixAccount=user \
-a objectClassMap=shadow:shadowAccount=user \
-a serviceSearchDescriptor=passwd:dc=TEST,dc=SOG,dc=COM?sub \
-a serviceSearchDescriptor=group:dc=TEST,dc=SOG,dc=COM?sub

# cp /etc/nsswitch.files /etc/nsswitch.conf

# vi /etc/nsswitch.conf
passwd files ldap
group files ldap
hosts files dns

# svcadm restart ldap/client

PAM

Edit /etc/pam.conf to use Kerberos authentication. Both sites provided at the top of this article show the same modifications to pam.conf. In our tests we found that those entries caused problems, most notably that the root user could not login from the console. Here is the /etc/pam.conf that we found to work best.

# vi /etc/pam.conf
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
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
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
#
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
# Default definition for Password management
# Used when service name is not explicitly mentioned for password management
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

Create home directory for user.

# mkdir -p /export/home/john.doe
# chown john.doe:staff /export/home/john.doe
# chmod 700 /export/home/john.doe

You should now be able to log into your Solaris system with your AD user account.

ABOUT US
Seeds of Genius, Inc. offers a full range of IT solutions including hardware and software products in addition to consulting, installation and support services. For more information, please visit our main web site at http://www.seedsofgenius.com or contact our Technical Sales department at (410) 312-9806.

Often times, password requirements may differ between the two system types. This means users will have to use a different password on Windows and Unix. Also, when password change dates are not synchronized between the Windows and Unix systems you’ll end with users that forget their Unix passwords on a very frequent basis.

This article is meant to provide the basic procedures to allow a Solaris system to use user information provided by Active Directory on a Windows 2008 server as the authentication method for logging into Solaris.

The following instructions are cobbled together from several locations on the internet and from in house testing.
We primarily used the following two sites, which offer steps on configuration using Windows 2003 R2. We then made changes where required.

Sun Wikis
Scott Lowe’s Blog

Our Test Environment

• Domain Controller Information
  • Windows 2008 R2
  • Hostname = win2k8-dc
  • IP Address = 192.168.3.76
  • Domain = test.sog.com
  • Kerberos Realm = TEST.SOG.COM
• Client Information
  • Solaris 10_u8 x86
  • Hostname = keystone
  • IP Address = 192.168.3.66

Windows Configuration

It is assumed that Active Directory is setup and that DNS is configured on the domain controller. The steps provided are what you need to do to add Unix functionality to an already existing Windows AD environment. The Solaris clients should be added to the DNS records on the DC.

The following steps are required to add all additional functionality to the domain controller to allow for Solaris clients to authenticate against AD.

Install UNIX Schema into Active Directory

Open “Server Manager” and click on “Roles” in the left pane. Click on “Add Role Services” in the “Active Directory Domain Services” section in the right pane.

Any users that you want to be able to use Active Directory for Solaris logins must have the Unix Attributes set under User Properties for that user. These properties include the UID, Primary GID, login shell, and home directory. (The users’ GECOS will come from the Display Name setting under the General tab of the users’ properties.)

Under Active Directory Users and Computers Right click the new user account and select Properties. In the user’s properties window select the Unix Attributes tab.

Select the domain under “NIS Domain” and fill in the fields.

All other user properties (secondary groups, RBAC roles/profiles/auths…) will come from the standard file locations on the Solaris client systems- (/etc/group, /etc/users, /etc/security/*attr)

Also, make sure that the user’s password is not set to ‘change at next login.’ Solaris does not have the hooks back into AD to do password management, so your user will not be prompted to change their password and they will not be allowed to login. All they will see is a messages saying: “Login Incorrect.”

Create Kerberos Keytab for Client System

Although this step is given on both of the sites provided above, I have found that it is not required to create a functioning Solaris -> AD authentication environment. I do not know the security implication of not performing this step.
On the Windows system, create a user account for the Solaris system that will be authenticating. In this example we are creating a user account named host-keystone for the host keystone. (Note: this is a user account, not a computer account)

Once this user is created you can disable it for security purposes.

The purpose of this step is create the keytab file that will be transferred to the /etc/krb5 directory of the Solaris system that will be authenticating against AD. In order to create the keytab file run the following command from a CMD prompt on the domain controller. (Make appropriate changes for you local environment.)

C:\Users\Administrator> ktpass –princ HOST\keystone.test.sog.com@TEST.SOG.COM -mapuser TEST\host-keystone –crypto DES-CBC-MD5 +DesOnly –pass p@ssword1 -ptype KRB5_NT_PRINCIPAL –out Desktop\keystone.keytab

Transfer the file to the host keystone as /etc/krb5/krb5.keytab

Create ProxyDN User Account

On the Windows system, create a user account that will be the proxyDN. Make this user a member of “Domain Guests.” Give it a password, and select ‘password never expires’
This will be the proxyDN username used when you run the ldapclient command later on. This account must remain enabled.
In this test we created a user account called “ProxyDNUser” with a password of “p@ssword1”

Make sure to use the Display Name under the General properties (Full Name when creating the user) during the ldapclient step. In this case the correct user to use during the ldapclient command will be ProxyDNUser. Do not use the user logon name. We ran into a bit of a problem when we kept trying to use the Windows logon name and we kept getting messages saying:

libsldap: Status: 49 Mesg: openConnection: simple bind failed – Invalid credentials

It was a bit frustrating when we were completely sure that we were using the right password and still kept getting a messages saying ‘Invalid Credentials.’

Use ADSIedit on your domain controller to see the full DN for the user account if you keep getting the message above and you’re positive you have the password correct.

Solaris Configuration

Client Side DNS Configuration

Your Solaris system should be a member of the DNS domain defined by your domain controller. Make sure to create both forward and reverse lookup records in the domain for the Solaris system.

# cat /etc/resolv.conf
domain test.sog.com
nameserver 192.168.3.76

Make sure you have the /etc/nsswitch.conf file setup to use DNS as a name service for hosts.

# grep ‘^hosts’ /etc/nsswitch.conf
hosts files dns

Verify that DNS works.

# nslookup `hostname`
Server: 192.168.3.76
Address: 192.168.3.76#53

Name: keystone.test.sog.com
Address: 192.168.3.66

The following nslookup commands should produce output similar to the following.

# nslookup -querytype=any _ldap._tcp
Server: 192.168.3.76
Address: 192.168.3.76#53

_ldap._tcp.test.sog.com service = 0 100 389 win2k8-dc.test.sog.com.

# nslookup -querytype=any _gc._tcp
Server: 192.168.3.76
Address: 192.168.3.76#53

_gc._tcp.test.sog.com service = 0 100 3268 win2k8-dc.test.sog.com.

Kerberos

Configure the /etc/krb5/krb5.conf file on the Solaris client. Make appropriate changes required for your local environment.
This is the /etc/krb5/krb5.conf that we used on our test system.

[libdefaults]
default_realm = TEST.SOG.COM
dns_lookup_kdc = true
verify_ap_req_nofail = false
[realms]
TEST.SOG.COM = {
kdc = WIN2K8-DC.TEST.SOG.COM
default_domain = TEST
admin_server = WIN2K8-DC.TEST.SOG.COM
}
[domain_realm]
.test.sog.com = TEST.SOG.COM
test.sog.com = TEST.SOG.COM
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {
period = 1d
versions = 10
}
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
kinit = {
renewable = true
forwardable= true
}

Run the kinit command and enter the administrator’s password. If the command runs successfully, you will see no output.

# kinit administrator
Password for administrator@TEST.SOG.COM:

LDAP

ldap client initialization on Solaris host. The part of the command in orange needs to be modified for your environment. The rest of the command is standard across all configurations.

# ldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN=cn=”ProxyDNUser,cn=Users,dc=TEST,dc=SOG,dc=COM” \
-a proxyPassword=p@ssword1 \
-a defaultSearchBase=dc=TEST,dc=SOG,dc=COM \
-a domainName=TEST.SOG.COM \
-a “defaultServerList=192.168.3.76″ \
-a attributeMap=group:userpassword=userPassword \
-a attributeMap=group:memberuid=memberUid \
-a attributeMap=group:gidnumber=gidNumber \
-a attributeMap=passwd:gecos=cn \
-a attributeMap=passwd:gidnumber=gidNumber \
-a attributeMap=passwd:uidnumber=uidNumber \
-a attributeMap=passwd:homedirectory=unixHomeDirectory \
-a attributeMap=passwd:loginshell=loginShell \
-a attributeMap=shadow:shadowflag=shadowFlag \
-a attributeMap=shadow:userpassword=userPassword \
-a objectClassMap=group:posixGroup=group \
-a objectClassMap=passwd:posixAccount=user \
-a objectClassMap=shadow:shadowAccount=user \
-a serviceSearchDescriptor=passwd:dc=TEST,dc=SOG,dc=COM?sub \
-a serviceSearchDescriptor=group:dc=TEST,dc=SOG,dc=COM?sub

# cp /etc/nsswitch.files /etc/nsswitch.conf

# vi /etc/nsswitch.conf
passwd files ldap
group files ldap
hosts files dns

# svcadm restart ldap/client

PAM

Edit /etc/pam.conf to use Kerberos authentication. Both sites provided at the top of this article show the same modifications to pam.conf. In our tests we found that those entries caused problems, most notably that the root user could not login from the console. Here is the /etc/pam.conf that we found to work best.

# vi /etc/pam.conf
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
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
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
#
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
# Default definition for Password management
# Used when service name is not explicitly mentioned for password management
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

Create home directory for user.

# mkdir -p /export/home/john.doe
# chown john.doe:staff /export/home/john.doe
# chmod 700 /export/home/john.doe

You should now be able to log into your Solaris system with your AD user account.

ABOUT US
Seeds of Genius, Inc. offers a full range of IT solutions including hardware and software products in addition to consulting, installation and support services. For more information, please visit our main web site at http://www.seedsofgenius.com or contact our Technical Sales department at (410) 312-9806.

Often times, password requirements may differ between the two system types. This means users will have to use a different password on Windows and Unix. Also, when password change dates are not synchronized between the Windows and Unix systems you’ll end with users that forget their Unix passwords on a very frequent basis.

This article is meant to provide the basic procedures to allow a Solaris system to use user information provided by Active Directory on a Windows 2008 server as the authentication method for logging into Solaris.

The following instructions are cobbled together from several locations on the internet and from in house testing.
We primarily used the following two sites, which offer steps on configuration using Windows 2003 R2. We then made changes where required.

Sun Wikis
Scott Lowe’s Blog

Our Test Environment

• Domain Controller Information
  • Windows 2008 R2
  • Hostname = win2k8-dc
  • IP Address = 192.168.3.76
  • Domain = test.sog.com
  • Kerberos Realm = TEST.SOG.COM
• Client Information
  • Solaris 10_u8 x86
  • Hostname = keystone
  • IP Address = 192.168.3.66

Windows Configuration

It is assumed that Active Directory is setup and that DNS is configured on the domain controller. The steps provided are what you need to do to add Unix functionality to an already existing Windows AD environment. The Solaris clients should be added to the DNS records on the DC.

The following steps are required to add all additional functionality to the domain controller to allow for Solaris clients to authenticate against AD.

Install UNIX Schema into Active Directory

Open “Server Manager” and click on “Roles” in the left pane. Click on “Add Role Services” in the “Active Directory Domain Services” section in the right pane.

Any users that you want to be able to use Active Directory for Solaris logins must have the Unix Attributes set under User Properties for that user. These properties include the UID, Primary GID, login shell, and home directory. (The users’ GECOS will come from the Display Name setting under the General tab of the users’ properties.)

Under Active Directory Users and Computers Right click the new user account and select Properties. In the user’s properties window select the Unix Attributes tab.

Select the domain under “NIS Domain” and fill in the fields.

All other user properties (secondary groups, RBAC roles/profiles/auths…) will come from the standard file locations on the Solaris client systems- (/etc/group, /etc/users, /etc/security/*attr)

Also, make sure that the user’s password is not set to ‘change at next login.’ Solaris does not have the hooks back into AD to do password management, so your user will not be prompted to change their password and they will not be allowed to login. All they will see is a messages saying: “Login Incorrect.”

Create Kerberos Keytab for Client System

Although this step is given on both of the sites provided above, I have found that it is not required to create a functioning Solaris -> AD authentication environment. I do not know the security implication of not performing this step.
On the Windows system, create a user account for the Solaris system that will be authenticating. In this example we are creating a user account named host-keystone for the host keystone. (Note: this is a user account, not a computer account)

Once this user is created you can disable it for security purposes.

The purpose of this step is create the keytab file that will be transferred to the /etc/krb5 directory of the Solaris system that will be authenticating against AD. In order to create the keytab file run the following command from a CMD prompt on the domain controller. (Make appropriate changes for you local environment.)

C:\Users\Administrator> ktpass –princ HOST\keystone.test.sog.com@TEST.SOG.COM -mapuser TEST\host-keystone –crypto DES-CBC-MD5 +DesOnly –pass p@ssword1 -ptype KRB5_NT_PRINCIPAL –out Desktop\keystone.keytab

Transfer the file to the host keystone as /etc/krb5/krb5.keytab

Create ProxyDN User Account

On the Windows system, create a user account that will be the proxyDN. Make this user a member of “Domain Guests.” Give it a password, and select ‘password never expires’
This will be the proxyDN username used when you run the ldapclient command later on. This account must remain enabled.
In this test we created a user account called “ProxyDNUser” with a password of “p@ssword1”

Make sure to use the Display Name under the General properties (Full Name when creating the user) during the ldapclient step. In this case the correct user to use during the ldapclient command will be ProxyDNUser. Do not use the user logon name. We ran into a bit of a problem when we kept trying to use the Windows logon name and we kept getting messages saying:

libsldap: Status: 49 Mesg: openConnection: simple bind failed – Invalid credentials

It was a bit frustrating when we were completely sure that we were using the right password and still kept getting a messages saying ‘Invalid Credentials.’

Use ADSIedit on your domain controller to see the full DN for the user account if you keep getting the message above and you’re positive you have the password correct.

Solaris Configuration

Client Side DNS Configuration

Your Solaris system should be a member of the DNS domain defined by your domain controller. Make sure to create both forward and reverse lookup records in the domain for the Solaris system.

# cat /etc/resolv.conf
domain test.sog.com
nameserver 192.168.3.76

Make sure you have the /etc/nsswitch.conf file setup to use DNS as a name service for hosts.

# grep ‘^hosts’ /etc/nsswitch.conf
hosts files dns

Verify that DNS works.

# nslookup `hostname`
Server: 192.168.3.76
Address: 192.168.3.76#53

Name: keystone.test.sog.com
Address: 192.168.3.66

The following nslookup commands should produce output similar to the following.

# nslookup -querytype=any _ldap._tcp
Server: 192.168.3.76
Address: 192.168.3.76#53

_ldap._tcp.test.sog.com service = 0 100 389 win2k8-dc.test.sog.com.

# nslookup -querytype=any _gc._tcp
Server: 192.168.3.76
Address: 192.168.3.76#53

_gc._tcp.test.sog.com service = 0 100 3268 win2k8-dc.test.sog.com.

Kerberos

Configure the /etc/krb5/krb5.conf file on the Solaris client. Make appropriate changes required for your local environment.
This is the /etc/krb5/krb5.conf that we used on our test system.

[libdefaults]
default_realm = TEST.SOG.COM
dns_lookup_kdc = true
verify_ap_req_nofail = false
[realms]
TEST.SOG.COM = {
kdc = WIN2K8-DC.TEST.SOG.COM
default_domain = TEST
admin_server = WIN2K8-DC.TEST.SOG.COM
}
[domain_realm]
.test.sog.com = TEST.SOG.COM
test.sog.com = TEST.SOG.COM
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {
period = 1d
versions = 10
}
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
kinit = {
renewable = true
forwardable= true
}

Run the kinit command and enter the administrator’s password. If the command runs successfully, you will see no output.

# kinit administrator
Password for administrator@TEST.SOG.COM:

LDAP

ldap client initialization on Solaris host. The part of the command in orange needs to be modified for your environment. The rest of the command is standard across all configurations.

# ldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN=cn=”ProxyDNUser,cn=Users,dc=TEST,dc=SOG,dc=COM” \
-a proxyPassword=p@ssword1 \
-a defaultSearchBase=dc=TEST,dc=SOG,dc=COM \
-a domainName=TEST.SOG.COM \
-a “defaultServerList=192.168.3.76″ \
-a attributeMap=group:userpassword=userPassword \
-a attributeMap=group:memberuid=memberUid \
-a attributeMap=group:gidnumber=gidNumber \
-a attributeMap=passwd:gecos=cn \
-a attributeMap=passwd:gidnumber=gidNumber \
-a attributeMap=passwd:uidnumber=uidNumber \
-a attributeMap=passwd:homedirectory=unixHomeDirectory \
-a attributeMap=passwd:loginshell=loginShell \
-a attributeMap=shadow:shadowflag=shadowFlag \
-a attributeMap=shadow:userpassword=userPassword \
-a objectClassMap=group:posixGroup=group \
-a objectClassMap=passwd:posixAccount=user \
-a objectClassMap=shadow:shadowAccount=user \
-a serviceSearchDescriptor=passwd:dc=TEST,dc=SOG,dc=COM?sub \
-a serviceSearchDescriptor=group:dc=TEST,dc=SOG,dc=COM?sub

# cp /etc/nsswitch.files /etc/nsswitch.conf

# vi /etc/nsswitch.conf
passwd files ldap
group files ldap
hosts files dns

# svcadm restart ldap/client

PAM

Edit /etc/pam.conf to use Kerberos authentication. Both sites provided at the top of this article show the same modifications to pam.conf. In our tests we found that those entries caused problems, most notably that the root user could not login from the console. Here is the /etc/pam.conf that we found to work best.

# vi /etc/pam.conf
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
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
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
#
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
# Default definition for Password management
# Used when service name is not explicitly mentioned for password management
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

Create home directory for user.

# mkdir -p /export/home/john.doe
# chown john.doe:staff /export/home/john.doe
# chmod 700 /export/home/john.doe

You should now be able to log into your Solaris system with your AD user account.

ABOUT US
Seeds of Genius, Inc. offers a full range of IT solutions including hardware and software products in addition to consulting, installation and support services. For more information, please visit our main web site at http://www.seedsofgenius.com or contact our Technical Sales department at (410) 312-9806.

Often times, password requirements may differ between the two system types. This means users will have to use a different password on Windows and Unix. Also, when password change dates are not synchronized between the Windows and Unix systems you’ll end with users that forget their Unix passwords on a very frequent basis.

This article is meant to provide the basic procedures to allow a Solaris system to use user information provided by Active Directory on a Windows 2008 server as the authentication method for logging into Solaris.

The following instructions are cobbled together from several locations on the internet and from in house testing.
We primarily used the following two sites, which offer steps on configuration using Windows 2003 R2. We then made changes where required.

Sun Wikis
Scott Lowe’s Blog

Our Test Environment

• Domain Controller Information
  • Windows 2008 R2
  • Hostname = win2k8-dc
  • IP Address = 192.168.3.76
  • Domain = test.sog.com
  • Kerberos Realm = TEST.SOG.COM
• Client Information
  • Solaris 10_u8 x86
  • Hostname = keystone
  • IP Address = 192.168.3.66

Windows Configuration

It is assumed that Active Directory is setup and that DNS is configured on the domain controller. The steps provided are what you need to do to add Unix functionality to an already existing Windows AD environment. The Solaris clients should be added to the DNS records on the DC.

The following steps are required to add all additional functionality to the domain controller to allow for Solaris clients to authenticate against AD.

Install UNIX Schema into Active Directory

Open “Server Manager” and click on “Roles” in the left pane. Click on “Add Role Services” in the “Active Directory Domain Services” section in the right pane.

Any users that you want to be able to use Active Directory for Solaris logins must have the Unix Attributes set under User Properties for that user. These properties include the UID, Primary GID, login shell, and home directory. (The users’ GECOS will come from the Display Name setting under the General tab of the users’ properties.)

Under Active Directory Users and Computers Right click the new user account and select Properties. In the user’s properties window select the Unix Attributes tab.

Select the domain under “NIS Domain” and fill in the fields.

All other user properties (secondary groups, RBAC roles/profiles/auths…) will come from the standard file locations on the Solaris client systems- (/etc/group, /etc/users, /etc/security/*attr)

Also, make sure that the user’s password is not set to ‘change at next login.’ Solaris does not have the hooks back into AD to do password management, so your user will not be prompted to change their password and they will not be allowed to login. All they will see is a messages saying: “Login Incorrect.”

Create Kerberos Keytab for Client System

Although this step is given on both of the sites provided above, I have found that it is not required to create a functioning Solaris -> AD authentication environment. I do not know the security implication of not performing this step.
On the Windows system, create a user account for the Solaris system that will be authenticating. In this example we are creating a user account named host-keystone for the host keystone. (Note: this is a user account, not a computer account)

Once this user is created you can disable it for security purposes.

The purpose of this step is create the keytab file that will be transferred to the /etc/krb5 directory of the Solaris system that will be authenticating against AD. In order to create the keytab file run the following command from a CMD prompt on the domain controller. (Make appropriate changes for you local environment.)

C:\Users\Administrator> ktpass –princ HOST\keystone.test.sog.com@TEST.SOG.COM -mapuser TEST\host-keystone –crypto DES-CBC-MD5 +DesOnly –pass p@ssword1 -ptype KRB5_NT_PRINCIPAL –out Desktop\keystone.keytab

Transfer the file to the host keystone as /etc/krb5/krb5.keytab

Create ProxyDN User Account

On the Windows system, create a user account that will be the proxyDN. Make this user a member of “Domain Guests.” Give it a password, and select ‘password never expires’
This will be the proxyDN username used when you run the ldapclient command later on. This account must remain enabled.
In this test we created a user account called “ProxyDNUser” with a password of “p@ssword1”

Make sure to use the Display Name under the General properties (Full Name when creating the user) during the ldapclient step. In this case the correct user to use during the ldapclient command will be ProxyDNUser. Do not use the user logon name. We ran into a bit of a problem when we kept trying to use the Windows logon name and we kept getting messages saying:

libsldap: Status: 49 Mesg: openConnection: simple bind failed – Invalid credentials

It was a bit frustrating when we were completely sure that we were using the right password and still kept getting a messages saying ‘Invalid Credentials.’

Use ADSIedit on your domain controller to see the full DN for the user account if you keep getting the message above and you’re positive you have the password correct.

Solaris Configuration

Client Side DNS Configuration

Your Solaris system should be a member of the DNS domain defined by your domain controller. Make sure to create both forward and reverse lookup records in the domain for the Solaris system.

# cat /etc/resolv.conf
domain test.sog.com
nameserver 192.168.3.76

Make sure you have the /etc/nsswitch.conf file setup to use DNS as a name service for hosts.

# grep ‘^hosts’ /etc/nsswitch.conf
hosts files dns

Verify that DNS works.

# nslookup `hostname`
Server: 192.168.3.76
Address: 192.168.3.76#53

Name: keystone.test.sog.com
Address: 192.168.3.66

The following nslookup commands should produce output similar to the following.

# nslookup -querytype=any _ldap._tcp
Server: 192.168.3.76
Address: 192.168.3.76#53

_ldap._tcp.test.sog.com service = 0 100 389 win2k8-dc.test.sog.com.

# nslookup -querytype=any _gc._tcp
Server: 192.168.3.76
Address: 192.168.3.76#53

_gc._tcp.test.sog.com service = 0 100 3268 win2k8-dc.test.sog.com.

Kerberos

Configure the /etc/krb5/krb5.conf file on the Solaris client. Make appropriate changes required for your local environment.
This is the /etc/krb5/krb5.conf that we used on our test system.

[libdefaults]
default_realm = TEST.SOG.COM
dns_lookup_kdc = true
verify_ap_req_nofail = false
[realms]
TEST.SOG.COM = {
kdc = WIN2K8-DC.TEST.SOG.COM
default_domain = TEST
admin_server = WIN2K8-DC.TEST.SOG.COM
}
[domain_realm]
.test.sog.com = TEST.SOG.COM
test.sog.com = TEST.SOG.COM
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {
period = 1d
versions = 10
}
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
kinit = {
renewable = true
forwardable= true
}

Run the kinit command and enter the administrator’s password. If the command runs successfully, you will see no output.

# kinit administrator
Password for administrator@TEST.SOG.COM:

LDAP

ldap client initialization on Solaris host. The part of the command in orange needs to be modified for your environment. The rest of the command is standard across all configurations.

# ldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN=cn=”ProxyDNUser,cn=Users,dc=TEST,dc=SOG,dc=COM” \
-a proxyPassword=p@ssword1 \
-a defaultSearchBase=dc=TEST,dc=SOG,dc=COM \
-a domainName=TEST.SOG.COM \
-a “defaultServerList=192.168.3.76″ \
-a attributeMap=group:userpassword=userPassword \
-a attributeMap=group:memberuid=memberUid \
-a attributeMap=group:gidnumber=gidNumber \
-a attributeMap=passwd:gecos=cn \
-a attributeMap=passwd:gidnumber=gidNumber \
-a attributeMap=passwd:uidnumber=uidNumber \
-a attributeMap=passwd:homedirectory=unixHomeDirectory \
-a attributeMap=passwd:loginshell=loginShell \
-a attributeMap=shadow:shadowflag=shadowFlag \
-a attributeMap=shadow:userpassword=userPassword \
-a objectClassMap=group:posixGroup=group \
-a objectClassMap=passwd:posixAccount=user \
-a objectClassMap=shadow:shadowAccount=user \
-a serviceSearchDescriptor=passwd:dc=TEST,dc=SOG,dc=COM?sub \
-a serviceSearchDescriptor=group:dc=TEST,dc=SOG,dc=COM?sub

# cp /etc/nsswitch.files /etc/nsswitch.conf

# vi /etc/nsswitch.conf
passwd files ldap
group files ldap
hosts files dns

# svcadm restart ldap/client

PAM

Edit /etc/pam.conf to use Kerberos authentication. Both sites provided at the top of this article show the same modifications to pam.conf. In our tests we found that those entries caused problems, most notably that the root user could not login from the console. Here is the /etc/pam.conf that we found to work best.

# vi /etc/pam.conf
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
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
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
#
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
# Default definition for Password management
# Used when service name is not explicitly mentioned for password management
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

Create home directory for user.

# mkdir -p /export/home/john.doe
# chown john.doe:staff /export/home/john.doe
# chmod 700 /export/home/john.doe

You should now be able to log into your Solaris system with your AD user account.

ABOUT US
Seeds of Genius, Inc. offers a full range of IT solutions including hardware and software products in addition to consulting, installation and support services. For more information, please visit our main web site at http://www.seedsofgenius.com or contact our Technical Sales department at (410) 312-9806.