I'm trying to use netgroup facilities with the SUN Native LDAP client installed on a Solaris 8 server.
I'm using Oracle Internet Directory (from Oracle Application Server 10G) for the LDAP server. It is installed on a Linux server.
Currently, this configuration is working properly with an AIX LDAP client.
Unfortunately, on Solaris, although I have access to LDAP user accounts, if I update the nsswitch.conf file regarding to your recommandations for using netgroup facilities, I'm no longer able to log with any of the LDAP user accounts.
Of course, I have followed all your recommandations, including the pam.conf file update and the following adds to the nisNetgroupTriple attribute from nis.schema on the LDAP server :
Just wonder, are you able to perform a simple "ldaplist" command on the Solaris Native LDAP Client?
$ ldaplist -l netgroup
If you can't, host access based on netgroup is not going to work.
The nisNetgroupTriple schema patch is provided by Diego in this URL, and it is meant for for OpenLDAP server, NOT meant for SUN DS, not sure if it will help Oracle Internet Directory.
I have no experience using OID, and am not sure if netgroups will work on OID, so far I have seen it works for SUN DS5.2 and OpenLDAP 2.2.X.
However, to make a Solaris Native LDAP Clients (Solaris8 or Solaris9) worked against OpenLDAP Server, I have to do a little hackings to make OpenLDAP Server acts like a SUN DS5.2 ldapclient profile(s) provider, described as in the following notes, against I have no idea if they are applicable to OID.
- Add "nisDomain" to rootDN so that "ldapclient" will be able to find this object.
- Add two schemas to the OpenLDAP Server, DUAConfigProfile.schema and solaris.schema, to support ldapclient proflles LDAP data.
- Apply a "result.c" patch to OpenLDAP server code, I don't know the corresponding OID changes if any, this again is to make "ldapclient" command worked.
- Create ou=profile subtree and add cn=ProxyAgent as a proxy credentials proxy user.
- Create "default" or "customized" ldapclient profile(s) under the ou=profile subtree for simple bind or simple bind + TLS or others, using ldif file or "ldapclient genprofile" command.
-Grant ACL, again I don't know the equivalent of OID, in OpenLDAP it is in slapd.conf (Note: the order it appears with respect to other ACLs is important to make sure it works)
===
access to dn="ou=People,dc=example,dc=com"
by self write
by dn="cn=proxyagent,ou=profile,dc=example,dc=com" read
by users auth
by anonymous read
==
-It is advisable to set password hash scheme to CRYPT in OID, as netgroups feature is sort of migrated from NIS to LDAP.
- It is advisable to add "shadowAccount" objectclass to your user entries in OID, on top of "posixAccount".
- Note that Solaris "ldapclient" has a irritating act that it reset the "hosts:" entry to "hosts: files ldap", this should be adjusted back to "hosts: files dns", otherwise something like telnet/ftp/ssh will break on hostname lookup.
You may refer to this URL for the above mentioned hacks.
While I am not well familiar with OID (or at all, for that matter), I do know for a fact that there are some applications that will not consult LDAP netgroups for authentication information. BEA Weblogic seems to be one of them, since I've not only tried about every way to get it to work, but also that their support has said that they don't support it (that should be the word, right?).
OID may require LDAP groups and user information directly, so you may need to configure in the bases for your user DN's and your group DN's.
In fact, as I said in my first message, when I don't use netgroup facilities (cf. nsswitch.conf file update), all is working fine and LDAP users can log into my server.
Here is the "ldapclient" command I used to configure my client :
passwd: compat
passwd_compat: ldap
group: files ldap
shadow: files ldap
# consult /etc "files" only if ldap is down.
hosts: files dns ldap
ipnodes: files
# Uncomment the following line and comment out the above to resolve
# both IPv4 and IPv6 addresses from the ipnodes databases. Note that
# IPv4 addresses are searched in all of the ipnodes databases before
# searching the hosts databases. Before turning this option on, consult
# the Network Administration Guide for more details on using IPv6.
#ipnodes: ldap [NOTFOUND=return] files
networks: ldap [NOTFOUND=return] files
protocols: ldap [NOTFOUND=return] files
rpc: ldap [NOTFOUND=return] files
ethers: ldap [NOTFOUND=return] files
netmasks: ldap [NOTFOUND=return] files
bootparams: ldap [NOTFOUND=return] files
publickey: ldap [NOTFOUND=return] files
netgroup: ldap
automount: files ldap
aliases: files ldap
# for efficient getservbyname() avoid ldap
services: files ldap
sendmailvars: files
# role-based access control
auth_attr: files ldap
exec_attr: files ldap
prof_attr: files ldap
user_attr: files ldap
# audit
audit_user: files ldap
project: files ldap
As you can see, my DIT differs from the one usualy set by SUN DS (i.e. "cn=Users" instead of "ou=People", ...)
I would like to know if the changes you applied to your OpenLDAP server are required only by the "ldapclient" command, at the configuration time. Or are they required for using netgroup facilities too.
A last thing : a Linux (SuZE) OpenLDAP client, I have configured, has a different behaviour : netgroups are supported except that the host field isn't taken in account.
The files that "ldapclient" configured are clearly stated in "man ldapclient", it does not seem to say anything about the netgroups.
So it is at your discretion to decide what you would like to do with OID configuration, you may check with Oracle tech supp if OID supports UNIX NIS style netgroups.
You may want to capture the debug output of "getent" and see if there is any useful info.
I have the same problem with netgroup. I'm using solaris 10 x86 with an openldap server on linux. Logging in with ldap users works fine. When I activate netgroup, login/su with an ldap user fails (the user is in the netgroup). The nis.schema on my openldap server is patched to match the rfc2307bis.
"getent passwd" lists the ldap user, but "getent passwd ldapuser" doesn't. I've included some command outputs and a truss.
I have not used any Solaris10 (x86 or sparc) LDAP clients, yet.
I am not sure if the following post at comp.unix.solaris would help you.
===
From: Jesse DeFer <easynews@dotd.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050217
MIME-Version: 1.0
Newsgroups: comp.unix.solaris
Subject: LDAP naming service with TLS on Solaris 10
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <4343r2-797.ln1@sacrifice.dotd.com>
Lines: 17
X-Complaints-To: abuse@easynews.com
Organization: EasyNews, UseNet made Easy!
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Thu, 21 Jul 2005 00:08:08 GMT
Path: news.starhub.net.sg!newsvr.starhub.net.sg!in.100proofnews.com!in.100proofnews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newsfeed2.easynews.com!easynews.com!easynews!easynews-local!fe04.news.easynews.com.POSTED!sacrifice.dotd.com!news
Xref: newscenter.starhub.net.sg comp.unix.solaris:313586
I was having problems with LDAP as a naming service with Solaris 10 with
TLS enabled. su would say 'Unknown id', while everything else appeared
to work. Thanks to Sun Support the fix is to add two directories to the
system trusted directory list with crle: /usr/lib/mps and /usr/lib/mps/64.
If you haven't already use crle to create an ld.config use:
crle -u -s /usr/lib/mps
crle -64 -u -s /usr/lib/mps/64
If you don't know if you have a custom ld.config or what the default
trusted directories are, just run crle with no arguments.
This only applies to Solaris 10 and is hopefully only a temporary fix
until they add that directory by default or move some libs around.
There may be other things related to LDAP and TLS it will fix too.
TLS isn't used in our setup. Nevertheless I created the directories with crle. The problem remains. As long as I don't use netgroups, everything works fine, but then any ldap user can login to any machine ...
Found my error. The nis.schema was restored in it's original form after restarting ldap. So I stopped ldap, patched the nis.schema and restarted ldap.
Now netgroups works fine.
1) The sample Solaris10 /etc/pam.conf could be found
at
http://docs.sun.com/app/docs/doc/816-4556/6maort2te?a=
view
(For this sample to work on Solaris8/9, commented out
all the pam_unix_cred.so.1 lines)
I should point out the keyword "binding" doesn't work in Solaris 8 or 9. I changed it to required and it appeared to work, however, SSH public/private keys won't work. (only password authentication.)
The keyword "binding" DOES WORK for Solaris8, ONLY after applying latest kernel patch and LDAP patch 108993-48. There is a RISK of not beling able to boot Solaris8 up if you do not have these patches. (You got to go into Single User mode to repair pam.conf it this happens).
When you do not specify "sshd" in /etc/pam.conf, it will default to follow the "other" entries for the PAM module actions. i.e.
# grep -v "^#" /etc/pam.conf | grep "^other"
other auth requisite pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth binding pam_unix_auth.so.1 server_policy
other auth required pam_ldap.so.1
other account requisite pam_roles.so.1
other account binding pam_unix_account.so.1 server_policy
other account required pam_ldap.so.1
other session required pam_unix_session.so.1
other password required pam_dhkeys.so.1
other password requisite pam_authtok_get.so.1
other password requisite pam_authtok_check.so.1
other password required pam_authtok_store.so.1 server_policy
#
You have the choice to explicitly define "sshd" entries in /etc/pam.conf by copying and pasting the above lines, and replace "other" with "sshd", and make further fine tuning if you do wish.
I replaced the pam.conf with the solaris 10 one and removed the unix_cred lines. Everything works except that SSH keys won't work (it always asks for password), and sudo stopped working (prompts for password and still fails after putting in correct password 3 times.)
SSH key based auth. has no concept of uid and userPassword, so why should it work with LDAP based acct? anyway I may be wrong and you got to ask OpenSSH developer.
sudo: I assume you are talking about sudo+LDAP, i.e. LDAP based sudo maps.
1) Did you compile sudo using "--with-pam"?
# sudo -V | head
Sudo version 1.6.8p8
Authentication methods: 'pam'
....
2) Did you setup a /etc/ldap.conf with content something like below, this file is usually not present for Solaris Native LDAP client but is used by the sudo code I believe.
host ldap1.example.com
base dc=example,dc=com
sudoers_base ou=sudoers,dc=example,dc=com
3) You may add "debug" keywords at the end of ALL lines in /etc/pam.conf and observe /var/adm/messages to troubleshooting sudo.
Email this Topic
Edit this Topic
