Thanks to some very helpful individuals in the #solaris channel on irc.freenode.net, I’ve been able to get ADS support working in Samba on Solaris 10, and thus have been able to incorporate the use of Samba in the Solaris 10-AD integration instructions.
To refer to earlier versions of the Solaris 10-AD integration instructions, see this article or this article. I would expect that you won’t need to refer to those posts, though, and will be able to get most of what you need directly from this post.
Assumptions
This procedure assumes that you are using Windows Server 2003 R2; if you are using a previous version, the LDAP attribute mapping will need to be modified to match the schema extensions found in Microsoft’s Services for Unix (SfU) add-on product. This will require changes to the “ldapclient manual” command shown below, which handles the schema/attribute mapping. (I only have a single article written that includes pre-R2 attribute mapping, and that’s this Linux-AD article. The schema mapping should be very, very similar between that article and Solaris 10.)
Preparing Active Directory (One-Time)
These steps only need to be performed once. Note that if you have performed any of these steps as part of authenticating Linux or Solaris to Active Directory, they do not need to be performed again. Simply make note of the information used earlier and re-use that information again this time.
- Install the “Server for NIS” component on at least one Active Directory domain controller (DC), so that the Active Directory schema can be extended to become partially RFC 2307-compliant. Installing this component will also add a “UNIX Attributes” tab to objects inside the Active Directory Users and Computers MMC console. You may also need to install the Server for NIS administrative tools on your workstation to see the “UNIX Attributes” tab.
- Use the Schema Management MMC snap-in to index the uid attribute, which is not indexed by default. This will speed up the login process and reduce the overall load on your DCs. (For more information, refer to the Linux-Windows Server 2003 R2 integration instructions.) It may be possible to change the attribute that Solaris is looking for, but I haven’t found a way to do that yet.
- Create an account in Active Directory that will be used to bind to Active Directory for LDAP queries. This account does not need any special privileges; in fact, making the account a member of Domain Guests and not a member of Domain Users is perfectly fine. I recommend giving this account a simple, short name; this will make specifying the DN of the account later easier to do.
- Create a global security group in Active Directory Users & Computers and set the UNIX attributes for this group.
Once these one-time steps have been completed, we can proceed to configuring the individual users that will be authenticating to Active Directory from your Solaris server(s).
Preparing Active Directory (Each User)
Each Active Directory account that will authenticate via Solaris must be configured with a uid and other UNIX attributes. This is accomplished via the new “UNIX Attributes” tab on the properties dialog box of a user account (this tab was made visible by the installation of the Server for NIS component). The attributes that must be populated are:
- NIS domain: It’s required on this tab in order to populate the other fields, but we won’t be using it.
- UID: This is actually the UID number. Each user must have a unique UID; I believe that the Server for NIS defaults at a starting UID of 10000, which is pretty safe for most systems.
- GID: In addition, each member must have a GID (group ID); simply specify the group that was created earlier.
- Login Shell: Specify a login shell (such as “usr/bin/csh” or “/sbin/sh”) for each user.
- Home Directory: Specify the home directory (such as “/export/home/slowe”) that will be used for this user. Keep in mind that these values may apply across multiple systems and platforms, and the path must be valid on all systems and platforms.
Based on my experience so far, the values for Solaris will often be very different than what might be specified for Linux-based logins. The only workarounds I’ve found to address these issues is the clever use of symlinks and the use of NFS automounts for home directories.
After all the user accounts have been configured, then we are ready to perform the additional tasks within Active Directory and on the Solaris server(s) that will enable the authentication.
Configuring Reverse DNS
On the DNS server handling the reverse lookup zones for the subnet on which the Solaris server is located, add a PTR record for the Solaris server and it’s IP address. This will ensure that reverse DNS lookups work as expected. Make sure that each Solaris server that will be authenticating against Active Directory has a reverse lookup record in DNS, and ensure that both forward and reverse lookups work from each of the Solaris server(s).
Configuring Solaris (Each Server)
The following steps need to be performed on each Solaris server that will authenticate against Active Directory.
Configuring the hosts file
To enable reliable TGT validation (this ensures that the Kerberos ticket returned by a KDC actually came from the KDC and not a spoofed server), you’ll need to edit the hosts file. On Solaris 10, this is found in /etc/inet/hosts and is read-only, even for root. Edit this file (changing permissions as necessary) so that the line with the server’s IP address looks something like this:
10.1.1.1 hostname.example.com hostname loghost
What we’re doing here is making sure that the server’s fully qualified domain name (not just the short hostname) is the first name entry on the line for the server’s IP address.
There may or may not be other entries in the file; leave those entries untouched (unless you know you need to modify them).
Installing Blastwave Packages
This is the key to getting ADS support into Samba on Solaris 10. I won’t go into excruciating detail on this since this process is amply covered elsewhere, but here’s the basic idea of the process:
- Use the standard wget (found in /usr/sfw/bin) to download the pkg-get file used by Blastwave.
- Use pkgadd to install pkg-get.
- Configure pkg-get to use the unstable packages (makes sure you get the latest builds).
- Use pkg-get to install the CSWsamba package and all requisite packages (there were quite a few dependency packages during my testing).
Once the CSWsamba package and related packages are installed, we’ll need to configure Samba by creating /opt/csw/etc/samba/smb.conf with the following contents:
workgroup = <NetBIOS name of AD domain>
security = ads
realm = <DNS name of AD domain in UPPERCASE>
use kerberos keytab = true
password server = <Space-delimited list of AD DCs>
At this point, we are ready to configure Kerberos and then proceed with testing the configuration and join the Active Directory domain.
Configuring Kerberos
Solaris keeps its Kerberos configuration in the /etc/krb5 directory as krb5.conf. Edit this file using your editor of choice to look something like the one below. Depending upon how you configured Solaris during the installation, some of this configuration may already be present.
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_kdc = true
[realms]
EXAMPLE.COM = {
kdc = dc01.example.com
kdc = dc02.example.com
admin_server = dc01.example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
.subdomain.example.com = EXAMPLE.COM
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {
period = 1d
version = 10
}
[appdefaults]
kinit = {
renewable = true
forwardable= true
}
There will also be a file named cswkrb5.conf in the /etc directory; you can configure this file with the contents of the [libdefaults], [reamls], and [domain_realms] sections as listed above. You don’t need to include the [logging] or [appdefaults] sections in this file.
Note that you can’t simply copy and paste from here to the Solaris configuration files, as you’ll need to customize your version for your particular network, hostnames, domain names, etc. If you must copy and paste from here, put it into a text editor first to customize it for your implementation.
Configuring LDAP
We’ll use the native Solaris “ldapclient” utility to configure the LDAP support in Solaris. The command you’ll type in looks something like this (please don’t copy and paste this, as it contains generic/incorrect information that won’t work!):
ldapclient manual \\
-a credentialLevel=proxy \\
-a authenticationMethod=simple \\
-a proxyDN=cn=proxyuser,cn=Users,dc=example,dc=com \\
-a proxyPassword=Password1 \\
-a defaultSearchBase=dc=example,dc=com \\
-a domainName=example.com \\
-a "defaultServerList=172.16.1.10" \\
-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=example,dc=com?sub \\
-a serviceSearchDescriptor=group:dc=example,dc=com?sub
The easiest way to handle this would probably be to copy it into a blank text file, edit it to include the specific details for your network, and then paste it into a terminal session on the Solaris server.
After this command has been run, Solaris will create the LDAP configuration in /var/ldap and will update /etc/nsswitch.conf to use LDAP. However, because we only want to use LDAP for specific purposes, we’ll need to go back and edit /etc/nsswitch.conf again. Just remove “ldap” from all entries in /etc/nsswitch.conf except for passwd and group.
While you’re editing /etc/nsswitch.conf, be sure to add a “dns” entry at the end of the line for hosts:
hosts files dns
This will help ensure that Solaris is properly configured to use DNS for host name resolution.
I think it’s necessary at this point to restart the LDAP client service:
svcadm restart svc:/network/ldap/client:default
Use the “svcs -a | grep ldap” command to verify the exact name of the LDAP client service on your Solaris server.
Configuring the DNS Client
You’ll also need to make sure that the DNS client is enabled and running. Using “svcs -a | grep dns” will help you identify the correct service, which you can then enable with svcadm:
svcadm enable svc:/network/dns/client:default
Test DNS resolution using the “nslookup” command. As mentioned previously, be sure to test both forward and reverse lookups.
Configuring PAM
The /etc/pam.conf file controls the PAM (Pluggable Authentication Mechanism) configuration on Solaris. You’ll need to edit the /etc/pam.conf file to look something like what’s shown below. I’ve edited away all the non-essential sections, so only change the sections listed below.
# Default definition for Authentication management
#
other auth requisite pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth sufficient pam_krb5.so.1
other auth required pam_unix_cred.so.1
other auth required pam_unix_auth.so.1
#
# Default definition for Account management
#
other account requisite pam_roles.so.1
other account sufficient pam_unix_account.so.1
other account required pam_ldap.so.1
#
With this configuration in place, Solaris will use Kerberos authentication and will retrieve account information via LDAP.
Reboot the Solaris Server
I know this sounds stupid, but even after restarting LDAP and enabling/starting/restarting the DNS client, things still didn’t work for me in the lab. However, after rebooting the Solaris server, it worked like a champ. So, just in case, reboot the Solaris server after completing the configuration.
Testing the Configuration
Once all of the configuration steps have been completed, you can test the configuration with the following commands:
- You can use “getent passwd <Name of AD user>” from the Solaris server; this command should return UID number, GID number, UNIX home directory, and login shell.
- You can use “kinit <Name of AD user>” to test Kerberos authentication. A succesful Kerberos test will not return any feedback, and the “klist” command will show a ticket granting ticket (TGT) from the Active Directory DC/KDC.
If either of these tests are unsuccessful, review the log files on the Solaris server and resolve the problems before continuing. Both of these tests will need to be successful in order for authentication to work correctly.
If the tests are successful, then you should now be able to join the Solaris server to Active Directory using Samba.
Joining the Solaris Server to Active Directory
This is the final step. Don’t try this step until you’ve successfully tested the configuration. After this step is completed, you are finished and AD users will be able to login to the Solaris server (assuming the AD users have been properly configured).
To join the Solaris server to Active Directory, follow these steps:
- Verify the Samba configuration as outlined earlier. Key to the configuration are the “security = ads” and “use kerberos keytab = true” directives.
- Use “kdestroy” to destroy any existing Kerberos credentials you may have; then run “kinit <Domain administrative account>@AD.DOMAIN.NAME” to get a Kerberos ticket for an account that is a domain administrator account.
- Run “net ads join” to join the Solaris server to Active Directory. This command will automatically create a computer object in Active Directory and add the appropriate SPNs (service principal names) to the computer object. In addition, it will populate the local Kerberos key table (/etc/krb5.keytab, by default) with the correct entries for authentication against Active Directory. You may see an error about a missing userPrincipalName, but this does not appear to affect any functionality.
At this point, all properly configured AD users (those users who have UNIX attributes) should be able to login to the Solaris server using their Active Directory username and password. Of course, this assumes that you’ve already dealt with home directories (or are automounting home directories).
As with previous instructions, these instructions don’t address password management (the ability to change an AD password from Solaris) and don’t address how to handle home directories. Hey, I’ve got to leave a few challenges for others to tackle, right?
How I Tested
This testing was done using Solaris 10 11/06 (Update 3) running on VMware ESX Server 3.0.1. Active Directory was running on a pair of servers with Windows Server 2003 R2, also virtual machines on ESX Server. Authentication testing was performed using SSH from a client system running Mac OS X.
Tags: ActiveDirectory, Interoperability, Kerberos, LDAP, Microsoft, Solaris, SSH, UNIX
-
Does the proxy DN need any access to the userPassword attribute? Can the ACL for the proxy DN be denied all access to it for security reasons? If the DN is ever compromised (it is on every Solaris machine) then an intruder could use it access LDAP records.
-
David,
Honestly, I don’t know the answer to your question. I do know that you can make the proxyDN account a Domain Guest, which severely limits access to Active Directory. I don’t know if making the account a Domain Guest also limits access to the userPassword attribute. Let me do some digging and I’ll see if I can come up with any additional information.
-
ok on this side. does it maintain username and privlidges, if you create a file with different usernames in the same directory?
-
The user’s password should be fairly well protected because of Kerberos itself, but since you’re connecting to the LDAP server via a plain-text bind:
-a authenticationMethod=simple
the proxy DN’s password can be exposed on the network. (It can also be possibly captured if your host is compromised, but then you usually have bigger issues.)
One way to protect the password over the network is to use a more secure LDAP bind method (via the ldapclient(1M) man page on Solaris 9):
sasl/CRAM-MD5
sasl/DIGEST-MD5
tls:simple
tls:sasl/CRAM-MD5
tls:sasl/DIGEST-MD5One issue with using TLS is that you have to import the certificate of the LDAP server (or perhaps just the CA’s that signed it). For this you need certutil, which isn’t always installed with Solaris by default:
http://www.mozilla.org/projects/security/pki/nss/
http://blogs.sun.com/baban/entry/steps_to_setup_ssl_usingI’ve read that it is available in Solaris 10 in /usr/sfw/bin/ if you install the SUNWtlsu package.
-
David,
Securing the LDAP bind traffic using SSL/TLS has been a top request of readers of the site, but something I haven’t had the opportunity to test extensively yet. There is also some documentation regarding the use of Kerberos to handle the LDAP bind, but I’ve not tested that either. Both of these methods would provide sufficient security for the LDAP bind operation.
I hope to be able to test this and post some results soon.
Steven,
I’m not sure I understand your question, but if you create a file on the Solaris machine while logged in as an AD account, the account will be owned by the UID of the AD account and permissions will be generated accordingly.
-
David,
I have obtained our AD CA cert and followed the certutil instructions in the blog you linked to…. however although ldapsearch with TLS appears to work fine if I set the authentication method to tls:simple instead of simple getent just hangs until I ^C… no errors I can see on the log at all… any ideas?
James
P.S. Scott I hope you do work out some TLS/kerberos binding soon - it will make my life a lot easier
-
I thought this would be helpful to some people….
Searching for a way to unify linux and solaris home directories - but locally (we do not wish to get into nfs yet) i was trying to find a pam_mkhomedir for solaris. Unfortunately, given that /home is virtual and a mount point in solaris 10, /home/%user% was not a valid location to create a directory. I thought about hacking pam_mkhomedir to create in /export/home/ instead but then I came upon this:
http://www.mail-archive.com/sunray-users@filibeto.org/msg06348.html
talk about using a sledgehammer to knock in a nail…….
one simple replacement for auto_home later and linux (using pam_mkhomedir although this could be adapted for that also) along with solaris both can use /home/%user% in the home directory field of the LDAP server with the directory automatically being created if it doesn’t already exist - happiness!
-
James,
Good tip! Thanks for sharing it here. I’m sure there are lots of people out there that will find this information useful.
-
James,
You may want to use strace(1M) to see what getent(1M) is doing. If you’re using Solaris 10 another option could be DTrace.
Unfortunately I don’t have a test setup to try things myself.
-
Hi Scott,
I’m curious how your sshd authenticates on the Solaris box, following your steps Samba places the host/fgqn@REALM key into /etc/krb5.keytab. However the native solaris utilities (including SSHD) will use the native Kerberos libraries (the old SEAM stuff) which are compiled with the keytab being /etc/krb5/krb5.keytab
# strings /usr/lib/gss/mech_krb5.so.1 | grep krb5.keytab
Bad magic number for krb5_keytab_entry structure
Bad magic number for krb5_keytab structure
FILE:/etc/krb5/krb5.keytabHave you installed another version of SSH?
Great articles by the way!
Rgds
Richard
-
Richard,
Great question! I had assumed that the installation of the additional Kerberos libraries (installed as part of the dependencies for the CSWsamba package from Blastwave) took care of that, but I honestly don’t know. I’m in the process of rebuilding the Solaris 10 11/06 server in my lab, so I’ll double-check the configuration and see if there was something else I did that I missed in the documentation. Thanks!
-
Scott,
Its not a show stopper, just a matter of copying /etc/krb5.keytab to /etc/krb5 directory. Didn’t seem to work by just copying the file so I used ktutil
I curiously also had to add a numerical value to the shadowFlag attribute as MMC didn’t seem to populate it. Without this pam_unix_account fails and prevented me from logging on.
Other than that worked like a charm!
Rgds
Richard
-
Scott,
First of all, thank you for your marvelous blog and all of the useful information I’ve been able to get from it. It’s truly been a lifesaver.
Now to my point - I have been able to successfully integrate Solaris10 and AD in a test environment using the above steps (basically, really - I’m not using samba, so I followed the old directions to get a keytab using ktpass, etc). When initially configuring ldapclient on the Solaris device (the working configuration), I set the service search descriptor for passwd/group to point to an OU containing all UNIX users that I have, and to do a subtree search, like so:
-a “serviceSearchDescriptor=passwd:ou=UNIX,?sub”
-a “serviceSearchDescriptor=group:ou=UNIX,?sub”That works just fine. However, I’d like to restrict logins to certain devices to only certain groups/users. I tested this by changing the passwd line to the following:
-a “serviceSearchDescriptor=passwd:ou=UNIX,?sub?(|(uid=testuser1)(uid=testuser2))”I verified the change by calling getent for several users. Only the two users specified were returned correctly; all other users were not in the passwd database, as expected. I thought I was good to go; however, I’ve found that I now can’t login remotely via SSH, Telnet, etc. What’s extra interesting is that when I SSH with the working configuration and enter an incorrect password, I get the “Kerberos Password” prompt as PAM does its magic and tries other methods. With this new configuration, I still get this with the incorrect password, but I don’t with the correct password - I just get another “normal” password prompt. That tells me that Kerberos is still auth’ing the user correctly, but something else is rejecting it (which I guess is expected, since I didn’t change anything Kerberos related, only LDAP).
Sorry for the extra long post, but I’m really hoping you can help me with my problem.
-
Hi Scott,
I really appreciate you collecting all these details and sharing them.
Got Solaris 10 11/06 and followed your procedure. Everything was working great right up to the net ads join. Users were able to SSH in with their AD domain accounts and everything. Seems to work with the kpass keytab until Samba joins the domain. I see the computer account in Active Directory and don’t get errors on the net ads join other than the one about the missing userPrincipalName. Once I do the join, none of the users can SSH in. Seems to be a Kerberos issue but I’m new to all of this.
-
Nate,
Are any error messages being logged to /var/adm/messages or other log files?
-
Thanks for the reply…
I was getting these errors:
Jun 14 17:59:35 maki sshd[1344]: [ID 537602 auth.error] PAM-KRB5 (auth): krb5_verify_init_creds failed: Server not found in Kerberos database -
Sounds like the realm-domain mapping in krb5.conf is incorrect. I’ve run into this error a number of times when the domain-realm mapping is either missing or incorrect. It may also be that the computer object in Active Directory is corrupted or damaged. You can delete the computer object and then re-create it with “net ads join” if you suspect that’s the problem.
Hope this helps!
-
Hmmm… tried leaving, deleting the computer object and rejoining but still having some issues. I did find a few things that might be having an influence on this like some tertiary DNS servers that are not the AD domain controllers. Tempted to try this out with Solaris Express Community Edition build 66 instead. Thanks - I’ll play around some more with this.
-
Hi Scott,
Good day.
I’m new to solaris OS and found myself interesting to know more about Solaris 10-AD Integration. Solaris 10 1/06 was installed and tried to follow your instructions. Unfortunately, I was not able to go further due to samba.has samba installed during Solaris OS installatin (10 1/06 )?
I did download “samba-3.0.25a-sol10-x86-local.gz” from sunfreeware.com. I tried to use “pkgadd filename”, but it was not able to install. Besides, “net” command was not found, as ran “net ads join”. Hence, kindly share some useful guides.
millions of thanks,
-
Kenneth,
The version of Samba that’s included with Solaris is not Active Directory-aware, so it can’t be used “as is”–you’ll need to install an AD-aware version of Samba. I’m sure the version from sunfreeware.com will work, but I can only help with the process of installing the version from Blastwave, as described in the article above. Give that a try and see if it helps.
In addition, I’d suggest trying a newer release of Solaris (this article was written with Solaris 10 11/06).
Good luck!
-
Hi Scott,
Thanks for this resource! It’s been a tremendous help, and I’ve learned several things from it.
I managed to get a Solaris10 test machine to authenticate against a test Windows server I have. It took a bit of tweaking, but I was able to get it to work. Now I am trying it with some live machines. I have it about half-working, but am now stuck. If I try to login with either a straight telnet session or from a dtlogin session I get “Login incorrect” and the following error shows on the console: “PAM-KRB5: krb5_verify_init_creds failed: No such file of directory.” Looking at the security logs on the Windows server shows the proxy account connecting, seemingly without problem. Yet, if I first log on locally to solaris as root, then ’su’ to one of the Active Directory user accounts, it works fine. It even automounts the home folder from the Windows server! Kinit and getent also work fine as root. But directly logging in as an AD user fails. I’ve triple and quadruple checked the krb5.conf file, ldap config, nsswitch.conf file, DNS settings, reset passwords, rebooted twenty times and still no luck. I’m sure it’s a typo or some other simple config error, but after hacking away at it for days I still can’t find it. It doesn’t help that this is my first effort at using either Kerberos or LDAP, so I’m also learning those along the way.
Do you (or anyone else out there) have a suggestion as to where to look?
I’m using Solaris 10, release 11/06, and Windows Server 2003R2.
Thanks!
-
Bingo! I knew once I asked for help, I’d find the problem. And I was right, it was something simple (and as it turn out, stupid). Since it seemed to be tripping over the kerberos settings somewhere along the chain I decided to just recreate all windows accounts and the keytab files from scratch. In doing so I discovered that somewhere in my previous actions I had managed to move the krb5.keytab file to krb5.keytab.old, but failed to save out a valid one again. I created new keytab files and now it’s working.
Thanks again for such a helpful site!
-
Brad,
I’m glad you found the site helpful and that you were able to find a resolution to your problem. Thanks for your feedback!
-
Hi, Scott…
Thanks for the very informative site. I’m curious if you’ve had much luck integrating with Solaris 9. I haven’t had problems on Solaris 10, but I’m having consistent problems on Solaris 9 similar to what Nate described above. After setting up Kerberos and getting everything going, I’m able to run kinit and get in, but when I try an connect via SSH, I’m consistently failing to authenticate. In /var/adm/messages, I get
sshd[14353]: [ID 537602 auth.error] PAM-KRB5 (auth): krb5_verify_init_creds failed: Server not found in Kerberos databaseNow, the only significant difference seems to be that I’m trying to join a server from one domain into another domain. For example:
AD server: test.outside.example.com (domain: outside.example.com)
Server trying to join: test1.example.com
Any suggestions?
-
Trevin,
Have you mapped the domains and realms in the /etc/krb5/krb5.conf file? In this case, it sounds like you need a line in the krb5.conf in the [domain_realm] section that looks like this:
.example.com = OUTSIDE.EXAMPLE.COM
This maps the example.com DNS domain to the OUTSIDE.EXAMPLE.COM Kerberos realm, which is where your AD DCs reside.
-
Hi,
I´m trying to follow your indications but I have some problems with the ldap part…. I dont know what exacly I need to change in the command to get it work with my configuration. I not really good on LDAP, so I would quite happy with any help
This is my command:
ldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN=cn=proxyuser,cn=Users,dc=DES-AXAPTA,dc=AND \
-a proxyPassword=master \
-a defaultSearchBase=dc=DES-AXAPTA,dc=AND \
-a domainName=DES-AXAPTA.AND \
-a “defaultServerList=SRVAX-4.DES-AXAPTA.AND†\
-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=DES-AXAPTA,dc=AND?sub \
-a serviceSearchDescriptor=group:dc=DES-AXAPTA,dc=AND?subAnd this is the answer on my system:
Error resetting system.
Recovering old system settings.
Stopping ldap failed with (7)
Error (1) while stopping services during resetAll on windows system have been done by the administrator of that enviroment…
-
Thank you. This will save me a lot of time.
-ron
-
Thank you for your great work! I have written a step-by-step procedure in how one could permorm a Solaris10 into Active Directory Integration including LDAP over SSL and Kerberos support for ssh putty.exe single-sign on.
http://www.csnc.ch/estatic/download/index.html#anchor%20Solaris10
Feedback is welcomed.
Ivan -
Does Solaris pick up supplementary groups from Active Directory for you?
I can’t get it to work, it only picks up the primary group from AD.
Which attribute mapping is used for supplementary groups?
Supplementary group membership is very important in our environment.
-
Nick,
Good question! Seems like I have gotten supplementary groups to work, although I can’t say that with absolute certainty. I’m hoping to have some lab time next week, so I’ll have a look at it then.
-
I’m wondering the same thing about secondary groups. The problem I’ve found is that AD (I’m using msSFU30 attributes) stores memberships within the group object as a Distinguised Name, not as a simple username.
The result, is that a “getent group somegroup” yields:
somegroup::9999:CN=Person,OU=users,DC=place,DC=com,DC=au,CN=Person2,OU=users,DC=place,DC=com,DC=au,CN=Person3,OU=users,DC=place,DC=com,DC=au
I’ve searched everywhere for weeks, and haven’t found a solution. Everything is working as it should, except for the fact that AD populates the msSFU30PosixMember field in this way. I could get around it by manually populating users into another field using adsiedit or something, but that’s a bit unmanageable
-
Hi Scott,
I’ve read through all your documentation both with Linux and Solaris 10 AD integration, and have gotten them to work successfully, but now I’m in a bind. In my particular instance, I can’t change the usernames that are configured in AD and the usernames aren’t compatible with UNIX in the sense that they start with numbers and they’re too long (which breaks the standard UNIX account name restrictions.) So, as an alternative, I decided to point the LDAP “passwd:uid” field to another field in AD via the ldapclient program. It works great… a “getent passwd ” brings up the entire line properly. (When I tried it against the illegal UNIX account name, it would return nothing, since it broke the UNIX restrictions.) The problem is this: Even though nss_ldap appears to work correctly, reading the /var/ldap/ldap_client_file right, pam_ldap does not seem to follow this convention. It doesn’t appear to be reading /var/ldap/ldap_client_file at all for the field mappings, because no matter how many times I change said file, pam_ldap still gives me an “illegal account name” or “account name not found” error in the debug lines from the messages or debug.log file I’ve set up via syslog. Would you know what file pam_ldap is attempting to read? I thought it might be some type of /etc/pam_ldap.conf file, but according to all the documentation I’ve read, it should be 100% compatible with /var/ldap/ldap_client_file. Lastly, all source code I look at is the Linux version of pam_ldap, which use completely different config files than the Solaris 10 version. Help!
Ian
-
Ok, I got it working. It turned out when I mapped passwd:uid to a new field under the attributeMap entries for ldapclient, I didn’t map shadow:uid as well. Because of this, when the system attempted to look up the password, it failed. (It was like having an entry in /etc/passwd, but not /etc/shadow.) Now that it’s in there, authentication against a new userid works perfectly. This way, Windows users can have a completely different UID from their Windows UID in UNIX.
Ian
-
Ian,
I’m glad you resolved it–that one had me stumped! I wasn’t sure what was going on. I think that I’ll be writing a little piece on exactly what you did (using “non-standard” attribute mapping) for those organizations that can’t/don’t want to extend their schema. This issue has come up a couple of times, so it seems like the time may be right.
Thanks for letting us know of the fix to your problem!
-
No problem… actually, I’ve run into ANOTHER snag. Since I can’t use Kerberos for authentication with AD, as I’ve manually mapped the attributes differently, I want to use pam_ldap.so to control the password changing for AD. But, every time I issue a “passwd” command against an AD user from Solaris 10, I get the following error:
passwd[3474]: [ID 293258 user.info] libsldap: Status: 50 Mesg: Insufficient access
I’ve tried to change all combinations of access and credentials with no success. I have a feeling that either a) the proxyuser I’m using to query the LDAP database has insufficient access (which I doubt, since its a member of Domain Admins), or b) SSL is not turned on, which Microsoft AD is immediately denying all password changing because of.
I’m running into independent issues with AD SSL integration, but that’s not topic for this conversation. kpasswd works perfectly against the original account name (not the aliased one.. Kerberos is not attribute-mapping aware.) so its the only thing I can think of that’s causing the issue.
Ian
-
Hi Scott,
Thank you so much for all your help. I have recommended your blog to my friends and all of them found it very useful.
I have managed to get the AD-Solaris 10 authentication working but not samba.
I have started smbd and nmbd and tried to map a network drive from a windows server but it didn’t work. It just kept asking for my username and password. Here’s the setting of my smb.conf:
#====== Global Settings ========
[global]workgroup = DEVLAB
security = ads
realm = DEVLAB.DEV.COM
use kerberos keytab = true
password server = PASSWD001 PASSWD002
server string = Samba Server
log file = /var/samba/log/log.%m#======= Share Definitions ========
[testing]
path = /home/jackiewong
public = no
writable = yes
printable = no[homes]
comment = Home Directories
read only = No
case sensitive = YesI am pretty sure it’s correct coz it works on Linux. I checked the samba log and got the following:
[2007/08/31 15:22:23, 0] nmbd/nmbd_incomingdgrams.c:(385)
process_master_browser_announce: Not configured as domain master - ignoring master announce.
[2007/08/31 15:25:22, 0] nmbd/nmbd_incomingdgrams.c:(385)
process_master_browser_announce: Not configured as domain master - ignoring master announce.
[2007/08/31 15:25:48, 0] nmbd/nmbd.c:(58)
Got SIGTERM: going down…
[2007/08/31 15:26:07, 0] nmbd/nmbd.c:(727)
Netbios nameserver version 3.0.21b started.
Copyright Andrew Tridgell and the Samba Team 1992-2006
[2007/08/31 15:26:07, 0] param/loadparm.c:(2645)
Unknown parameter encountered: “realmâ€
[2007/08/31 15:26:07, 0] param/loadparm.c:(3390)
Ignoring unknown parameter “realmâ€Would you please give me some advice? Thank you very much.
Regards,
Jackie -
Jackie,
The version of Samba that is installed with Solaris 10 does not support Active Directory. You’ll need to install the Blastwave version as described in the section “Installing Blastwave Packages”. As evidenced by the output of the Samba log above (note error about realm being an unknown parameter), the version you’re using apparently does not have AD support.
Once you get a version that has AD support, you should be OK.
-
Hi Scott,
Thanks a lot for your help. I really find that all the documents on your blog are extremely useful and really have made my life a lot easier. I will definitely recommend it to my friends.
Cheers,
Jackie -
Was the question about supplementary groups ever solved? Right now it looks like this might work in our environment except that we don’t have any group listings except for primary.
-
Is the possible to restrict a ADS user to login to a unix client like “logon to” option in user property in ADS”
-
This configuration worked for me.
Note:My users are in top level domain.ldapclient -vvv manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN=CN=administrator,CN=Users,DC=eng,DC=int,DC=balaji,DC=com \
-a proxyPassword=Balaji \
-a defaultSearchBase=CN=users,DC=eng,DC=int,DC=balaji,DC=com \
-a defaultServerList=10.50.50.50:389 \
-a domainName=eng.int.balaji.com \
-a attributeMap=group:userpassword=msSFU30Password \
-a attributeMap=group:memberuid=msSFU30MemberUid \
-a attributeMap=group:gidnumber=msSFU30GidNumber \
-a attributeMap=passwd:gecos=msSFU30Gecos \
-a attributeMap=passwd:gidnumber=msSFU30GidNumber \
-a attributeMap=passwd:uidnumber=msSFU30UidNumber \
-a attributeMap=passwd:uid=sAMAccountName \
-a attributeMap=passwd:homedirectory=msSFU30HomeDirectory \
-a attributeMap=passwd:loginshell=msSFU30LoginShell \
-a attributeMap=shadow:shadowflag=msSFU30ShadowFlag \
-a attributeMap=shadow:userpassword=msSFU30Password \
-a attributeMap=shadow:uid=sAMAccountName \
-a objectClassMap=group:posixGroup=group \
-a objectClassMap=passwd:posixAccount=user \
-a objectClassMap=shadow:shadowAccount=user \
-a serviceSearchDescriptor=passwd:CN=users,DC=eng,DC=int,DC=balaji,DC=com?sub \
-a serviceSearchDescriptor=group:DC=CN=Users,eng,DC=int,DC=balaji,DC=com?sub -
Nope, the supplementary group question remains. Are we the only people who use more than our primary groups, or has everybody else who’s implemented this just not noticed their other groups no longer work?
I’m not sure there is an answer though sadly — I’ve been scouring the internet for months.
Thanks to Scott though, for getting us up to this point!
-
Balaji,
With regards to restricting user access to UNIX systems, there are a couple of ways of handling that. For one, check http ://blog.scottlowe.org/2006/09/08/ldap-based-access-control/ which describes a way using LDAP.
Also, thanks for posting your LDAP configuration in case it can be helpful to someone else!
-
In case anyone else has any more info this is the printout of a group via ldaplist. You can see the member of the group here, but doing getent group does not display any members, only gid. Any ideas?
root@ackbar:/usr/local/src$ ldaplist -l group cens_test
dn: CN=cens_test,OU=CENS Users and Groups,OU=CENS Labs,DC=students,DC=froot,DC=nau,DC=edu
objectClass: top
objectClass: posixGroup
cn: cens_test
member: CN=Christian,OU=CENS Users and Groups,OU=CENS Labs,DC=students,DC=froot,DC=nau,DC=edu
member: CN=mcm75,CN=Users,DC=students,DC=froot,DC=nau,DC=edu
distinguishedName: CN=cens_test,OU=CENS Users and Groups,OU=CENS Labs,DC=students,DC=froot,DC=nau,DC=edu
instanceType: 4
whenCreated: 20070912202323.0Z
whenChanged: 20070912202440.0Z
uSNCreated: 39801811
uSNChanged: 39801867
name: cens_test
objectGUID:
objectSid:
sAMAccountName: cens_test
sAMAccountType: 268435456
groupType: -2147483646
objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=froot,DC=nau,DC=edu
gidnumber: 1200
msSFU30NisDomain: nauunix -
Hi Scott,
I’ve tried to configure AD support under Solaris 10, but have runned into some troubles with Solaris native LDAP client. It seems to require RFC2307bis support (nisDomainObject and other attributes), while Windows 2003 Server R2 officially supports only RFC2307.. It says that it can not find nisDomainObject under the top branch of the directory. So I’ve tried your steps several times, and ldapclient still is not working seamlessly. I doublechecked all the configs - they are exactly the same as you described with fixes regarding my own configuration.
Could you tell me please, am I need some specific version of Solaris and ldapclient? Am I missed something?
Best regards,
Nick. -
Nick,
I didn’t do anything special–I’m using Solaris 10 Update 3 straight “out of the box”. What kind of errors are you getting specifically?
-
Is the possible to restrict a ADS user to login to a unix client like “logon to†option in user property in ADSâ€
my ldapclient is solaris10
-
Scott,
Here is an output of the command
#ldapclient -v init dc.domain.com
Arguments parsed:
defaultServerList: dc.domain.com
Handling init option
About to configure machine by downloading a profile
No profile specified. Using “default”
findBaseDN: begins
findBaseDN: Stopping ldap
findBaseDN: calling __ns_ldap_default_config()
found 5 namingcontexts
findBaseDN: __ns_ldap_list(NULL, “(&(objectclass=nisDomainObject)(nisdomain=domain.com))”
rootDN[0] DC=RENCDDC,DC=DOM
NOTFOUND:Could not find the nisDomainObject for DN DC=DOMAIN,DC=COM
findBaseDN: __ns_ldap_list(NULL, “(&(objectclass=nisDomainObject)(nisdomain=domain.com))”
rootDN[1] CN=Configuration,DC=DOMAIN,DC=COM
NOTFOUND:Could not find the nisDomainObject for DN CN=Configuration,DC=DOMAIN,DC=COM
findBaseDN: __ns_ldap_list(NULL, “(&(objectclass=nisDomainObject)(nisdomain=domain.com))”
rootDN[2] CN=Schema,CN=Configuration,DC=DOMAIN,DC=COM
NOTFOUND:Could not find the nisDomainObject for DN CN=Schema,CN=Configuration,DC=DOMAIN,DC=COM
findBaseDN: __ns_ldap_list(NULL, “(&(objectclass=nisDomainObject)(nisdomain=domain.com))”
rootDN[3] DC=DomainDnsZones,DC=DOMAIN,DC=COM
NOTFOUND:Could not find the nisDomainObject for DN DC=DomainDnsZones,DC=DOMAIN,DC=COM
findBaseDN: __ns_ldap_list(NULL, “(&(objectclass=nisDomainObject)(nisdomain=domain.com))”
rootDN[4] DC=ForestDnsZones,DC=DOMAIN,DC=COM
NOTFOUND:Could not find the nisDomainObject for DN DC=ForestDnsZones,DC=DOMAIN,DC=COM
found_cxt = -1
findBaseDN: Err exit
Failed to find defaultSearchBase for domain domain.comMy Solaris version is Solaris 10 3/05 s10_74L2a released January 2005. It seems a kind of not updated one..
-
Nick,
I can only surmise that your version of Solaris 10 does not provide the necessary support. The earliest version I tested was Solaris 10 11/06, I believe (I may have tested 6/06 as well; can’t recall for certain).
-
Slowe,
-a “serviceSearchDescriptor=passwd:CN=Users,DC=eng,DC=int,DC=rci,DC=com?sub?userWorkstations=$HOSTNAME” \
-a “serviceSearchDescriptor=shadow:CN=Users,DC=eng,DC=int,DC=rci,DC=com?sub?userWorkstations=$HOSTNAME” \
-a “serviceSearchDescriptor=group:CN=Users,DC=eng,DC=int,DC=rci,DC=com?sub”this service search descriptor filters the users with workstation defined in windows user properties, but allow only one work station to define, please do you have any idea if a user has 2 3 workstation defined in the windows profile.
Your help is really appreciated.
Thanks in advance.
Site Sponsors
152 comments
Comments feed for this article
Trackback link: http://blog.scottlowe.org/2007/04/25/solaris-10-ad-integration-version-3/trackback/