Am 11.10.2011 22:12, schrieb NetNinja:
I tryed your command today. I still can't get it to work. I listed all the files I have edited. Can you look over it and tell if I'm missing anything. Thanks for your help.
Please keep your replies on the list. Others might run into similar problems and find this helpful.
I ran this: ldapclient manual -v -a defaultSearchBase="dc=test,dc=net" -a domainName="test.net" -a authenticationMethod="simple" -a defaultServerList="10.0.0.2" -a preferredServerList="10.0.0.2" -a serviceSearchDescriptor="passwd:ou=People,dc=test,dc=net" -a serviceSearchDescriptor="group:ou=Group,dc=test,dc=net" 10.0.0.2
I don't have TLS, automount or netgroups setup yet.
bash-3.00# ldapclient list NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_SERVERS= 10.0.0.2 NS_LDAP_SEARCH_BASEDN= dc=test,dc=net NS_LDAP_CACHETTL= 0 NS_LDAP_SERVICE_SEARCH_DESC= passwd:ou=People,dc=test,dc=net NS_LDAP_SERVICE_SEARCH_DESC= group:ou=Group,dc=test,dc=net
I tried to add more lines but I was getting a lot of errors.
What kind of errors?
/etc/nsswitch.conf passwd: files ldap group: files ldap host: files ldap
Are you sure you want to resolve hostnames via LDAP and not DNS?
what i have running on RHEL ldapsearch -x
<snip>
---------------- I have added a proxy entry before I have not done so yet. Do I still need one if I'm useing manual and not init?
If your data can be accessed anonymously, you don't need proxy credentials.
My PAM file
# 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_unix_auth.so.1 login auth required pam_dial_auth.so.1 login auth required pam_ldap.so.1
My "auth" blocks look like this:
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 required pam_dial_auth.so.1 login auth sufficient pam_ldap.so.1 use_first_pass ignore_unknown_user login auth required pam_unix_auth.so.1
# # rlogin service (explicit because of pam_rhost_auth) # rlogin auth sufficient pam_rhosts_auth.so.1 rlogin auth requisite pam_authtok_get.so.1 rlogin auth required pam_dhkeys.so.1 rlogin auth required pam_unix_cred.so.1 rlogin auth sufficient pam_unix_auth.so.1 rlogin auth required pam_ldap.so.1 # # Kerberized rlogin service # krlogin auth required pam_unix_cred.so.1 krlogin auth required pam_krb5.so.1 # # rsh service (explicit because of pam_rhost_auth, # and pam_unix_auth for meaningful pam_setcred) # rsh auth sufficient pam_rhosts_auth.so.1 rsh auth required pam_unix_cred.so.1 # # Kerberized rsh service # krsh auth required pam_unix_cred.so.1 krsh auth required pam_krb5.so.1 # # Kerberized telnet service # ktelnet auth required pam_unix_cred.so.1 ktelnet auth required pam_krb5.so.1 # # PPP service (explicit because of pam_dial_auth) # ppp auth requisite pam_authtok_get.so.1 ppp auth required pam_dhkeys.so.1 ppp auth required pam_unix_cred.so.1 ppp auth sufficient pam_unix_auth.so.1 ppp auth required pam_dial_auth.so.1 ppp auth required pam_ldap.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_unix_auth.so.1 other auth required pam_dial_auth.so.1 other auth required pam_ldap.so.1 # # passwd command (explicit because of a different authentication module) # passwd auth sufficient pam_passwd_auth.so.1 passwd auth required pam_ldap.so.1 # # cron service (explicit because of non-usage of pam_roles.so.1) # cron account required pam_unix_account.so.1 # # Default definition for Account management # Used when service name is not explicitly mentioned for account management # other account sufficient pam_ldap.so.1 other account requisite pam_roles.so.1 other account required pam_unix_account.so.1
You can omit pam_ldap here. It only produces error messages in the logs for me.
# # Default definition for Session management # Used when service name is not explicitly mentioned for session management # other session required pam_unix_session.so.1 # # Default definition for Password management # Used when service name is not explicitly mentioned for password management # 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 #
On Sun, Oct 9, 2011 at 10:31 AM, Christian Manal moenoel@informatik.uni-bremen.de wrote:
Am 09.10.2011 14:33, schrieb NetNinja:
On Sat, Oct 8, 2011 at 4:54 AM, Christian Manal moenoel@informatik.uni-bremen.de wrote:
Am 07.10.2011 23:58, schrieb NetNinja:
Ok that's good to know. I was reading in the book "Solaris 10 System Administration Essential" and it says on pg 365 that the openldap server needs to be patched so that the ldapclient init utility will configure properly.
Do you happen to remeber how you setup the Solaris Native client? This my current issue, I installed openldap on a RHEL 5.5 server and have all the Linux servers working with the ldap server but the Solaris servers won't let me login as a ldap user. I can do a ldapsearch, id, getent and get info on ldap users. I am in the process of troubleshooting the issue and I'm not sure what I'm doing wrong? My setup is very basic, no TLS, uatomount or replication. I will add these later when I know what i'm doing.
Anyway thanks for your help. If you have any advice on ldapclient setup let me know.
On Fri, Oct 7, 2011 at 3:41 PM, Christian Manal <moenoel@informatik.uni-bremen.de mailto:moenoel@informatik.uni-bremen.de> wrote:
Am 07.10.2011 20:25, schrieb NetNinja: > Hello, > I have been reading up on OpenLDAP. I have installed it on RHEL 5.5 but > I have seen documention saying that openldap needs to be patched to work > with Solaris. Can someone tell me if this still the case and if so where > to get the patch. If not any info you can provide wold be great. > > Thanks > > Hi, I've been running OpenLDAP on Solaris 10 for years now. It works out of the tarball, no patches needed. Regards, Christian Manal
Here's an example of an ldapclient invocation that works for me:
ldapclient manual \ -a authenticationMethod="tls:simple" \ -a credentialLevel="proxy" \ -a defaultSearchBase="dc=example,dc=org" \ -a defaultSearchScope="sub" \ -a defaultServerList="ldap1.example.org,ldap2.example.org" \ -a domainName="example.org" \ -a preferredServerList="ldap1.example.org,ldap2.example.org" \ -a serviceSearchDescriptor="passwd:ou=People,dc=example,dc=org" \ -a serviceSearchDescriptor="group:ou=Group,dc=example,dc=org" \ -a serviceSearchDescriptor="netgroup:ou=Netgroup,dc=example,dc=org" \ -a serviceSearchDescriptor="auto_home:ou=auto_home,ou=Mounts,dc=example,dc=org" \ -a attributeMap="auto_home:automountMapName=ou" \ -a attributeMap="auto_home:automountKey=cn" \ -a proxyDN="uid=proxyauth,ou=people,dc=example,dc=org" \ -a proxyPassword="foobar"
Before you invoke that, you need to modify /etc/nsswitch.ldap to your needs (ldapclient will copy that to /etc/nsswitch.conf). You also need to put your TLS certs into /var/ldap in NSS format (you can generate/convert them with certutil[1]) and edit /etc/pam.conf for LDAP authentication.
Regards, Christian Manal
[1] http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html
Thanks,
I will try your command. Since you used ldapclient manual and not ldapclient init I don't need to add a profile of proxy ldif file to the ldap server, right?
Right. It's possible to deposit most of those infos in a profile in the DIT, but since I have a script for configuring LDAP clients it doesn't make any difference for me. I have only one set of settings for Solaris boxes. Though, it might be worth looking into for you, if you have different setups.
I have been using examples like the one you just gave me and I can only get the info from the server. The password seems to not work. I get the same erros on the prompt that I would get if the password or username where wrong. Though I have not tried the command with the serviceSearchDescriptor before maybe this is what I'm missing.
You replaced the credentials with existing ones from your DIT, right? Do they work with ldapsearch? Does the DN have read access to the user and group data in your DIT?
You might want to call ldapclient with '-v' to get some debugging info.
I'm also not using TLS or automount can I leave these out, for now? Sotls:simple would be simple, right.
Right.
Also could Solaris 10 not want to work because I'm not using TLS?
I don't think so. It shouldn't make any difference. Though, I'd recommend adding TLS support before putting anything in production.
Anyway thanks for your time. I will let you know if it works.
Regards, Christian Manal