Re: [389-users] Stumped - SSL works for auth, sudo, etc, but fails for ldap user cronjobs
Hi, what kind of certificate do you use, selfsigned? Are the certificates signed by the same CA? Am 18.07.12, schrieb David Nguyen d_k_ngu...@yahoo.com: Hi all, I have a strange one. My current setup is working perfectly. client1 is able to connect to ldap-server1 via SSL and everything is working correctly. I then had a need to add another ldap server (ldap-server2) as a multi-master replica and everything is working (user auth, sudo via ldap users, ldapsearch, openssl, etc) except cronjobs for users served out of ldap fail to run. I can see this in the error log on ldap-server2: [18/Jul/2012:11:18:00 -0700] - PR_Recv for connection 467 returns -12195 (Peer does not recognize and trust the CA that issued your certificate.) If I set /etc/ldap.conf to not use SSL (URI ldap://fqdn vs URI ldaps://fqdn:636), the cronjobs fire just fine. So it appears as though there is an SSL cert issue, but I'm stumped because all of the other services that use ldap on client1 work except cron jobs (root cron fires fine as expected since nsswitch is set to files then ldap). If I replace the URI string in /etc/ldap.conf to point at ldap-server1, cron starts working. Both ldap-server1 and ldap-server2 are using running the same OS and kernel version (RHEL5) as well as the same version of 389 DS (389-ds-1.2.1-1.el5). Any ideas as to what could be causing this problem? Here is the /etc/ldap.conf on client1 if it matters: == begin /etc/ldap.conf === URI ldaps://ops-ldap006.svale.netledger.com:636 base dc=netsuite,dc=com timelimit 10 bind_policy soft nss_reconnect_tries 3 bind_timelimit 6 idle_timelimit 30 sudoers_base ou=SUDOers,dc=netsuite,dc=com sudoers_debug 0 ##ssl start_tls TLS_CACERT /etc/openldap/cacerts/ca.crt TLS_CACERTFILE /etc/openldap/cacerts/ca.crt TLS_REQCERT demand pam_lookup_policy yes pam_password exop nss_initgroups_ignoreusers root,named,avahi,haldaemon,dbus,gdm,postfix,puppet == end /etc/ldap.conf === Thanks in advance, David -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- Carsten Grzemba -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] Keep the schema or change it?
Hi, I am in the process of migrating from Sun's DS 5.2 to DS 389 and I have compared the schemata. I see some differences and I wonder as to the best way to handle them. In general is it better to change the 389 schema and then always have to fix it with each new release or change my Sun clients somehow (this seems to border on the philosophical)? As an example, there is the Automount schema. On Sun's systems, they expect something schema like this: objectClasses: ( 1.3.6.1.1.1.2.17 NAME 'automount' MUST ( automountKey $ automountInformation ) MAY description ...) with the 389 schema looking like this: objectclasses: ( 1.3.6.1.1.1.2.17 NAME 'automount' MUST ( cn $ automountInformation ) MAY description ...) In other words, the lookup key matched against the user's login for home directories would be automountKey for Sun, and cn for 389. I notice that my Linux clients work fine with a Sun DS so they seem to be using automountKey. (Or are they looking for either?). I also see differences in the objectClass automountMap. Linux does not seem to work with a Sun-style autmountMap. If I just dump my Sun DS and load it into the 389 DS do I want to overwrite the schema? Should I only load the non-conflicting entries? If the 389 schema is the right schema, will Linux stop working some day when they conform? Is there a way to have both? I have about 500 mixed Sun and Linux clients and I want to minimize the reconfiguration on the day that I switch DS. -- Gary Algier, WB2FWZ gaa at ulticom.com +1 856 787 2758 Ulticom Inc., 1020 Briggs Rd, Mt. Laurel, NJ 08054 Fax:+1 856 866 2033 Nielsen's First Law of Computer Manuals: People don't read documentation voluntarily. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Keep the schema or change it?
On 07/19/2012 10:28 AM, Gary Algier wrote: Hi, I am in the process of migrating from Sun's DS 5.2 to DS 389 and I have compared the schemata. I see some differences and I wonder as to the best way to handle them. In general is it better to change the 389 schema and then always have to fix it with each new release or change my Sun clients somehow (this seems to border on the philosophical)? As an example, there is the Automount schema. On Sun's systems, they expect something schema like this: objectClasses: ( 1.3.6.1.1.1.2.17 NAME 'automount' MUST ( automountKey $ automountInformation ) MAY description ...) with the 389 schema looking like this: objectclasses: ( 1.3.6.1.1.1.2.17 NAME 'automount' MUST ( cn $ automountInformation ) MAY description ...) In other words, the lookup key matched against the user's login for home directories would be automountKey for Sun, and cn for 389. Looks like Sun is using the RFC 2307 bis schema? Try this - remove the default /etc/dirsrv/slapd-INSTANCE/schema/10rfc2307.ldif schema, and instead copy in the /usr/share/dirsrv/ldif/10rfc2307bis.ldif I notice that my Linux clients work fine with a Sun DS so they seem to be using automountKey. (Or are they looking for either?). I also see differences in the objectClass automountMap. Linux does not seem to work with a Sun-style autmountMap. If I just dump my Sun DS and load it into the 389 DS do I want to overwrite the schema? Should I only load the non-conflicting entries? If the 389 schema is the right schema, will Linux stop working some day when they conform? Is there a way to have both? I have about 500 mixed Sun and Linux clients and I want to minimize the reconfiguration on the day that I switch DS. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Stumped - SSL works for auth, sudo, etc, but fails for ldap user cronjobs
The cert is self-signed, but by different CA's (each server has it's own CA). You know what? I took your hint and signed a new server cert using the working ldap server's CA and voila, it started working. Thank you so much! I've been scratching my head over this one for days David On Thu, Jul 19, 2012 at 6:34 AM, Carsten Grzemba grze...@contac-dt.de wrote: Hi, what kind of certificate do you use, selfsigned? Are the certificates signed by the same CA? Am 18.07.12, schrieb David Nguyen d_k_ngu...@yahoo.com: Hi all, I have a strange one. My current setup is working perfectly. client1 is able to connect to ldap-server1 via SSL and everything is working correctly. I then had a need to add another ldap server (ldap-server2) as a multi-master replica and everything is working (user auth, sudo via ldap users, ldapsearch, openssl, etc) except cronjobs for users served out of ldap fail to run. I can see this in the error log on ldap-server2: [18/Jul/2012:11:18:00 -0700] - PR_Recv for connection 467 returns -12195 (Peer does not recognize and trust the CA that issued your certificate.) If I set /etc/ldap.conf to not use SSL (URI ldap://fqdn vs URI ldaps://fqdn:636), the cronjobs fire just fine. So it appears as though there is an SSL cert issue, but I'm stumped because all of the other services that use ldap on client1 work except cron jobs (root cron fires fine as expected since nsswitch is set to files then ldap). If I replace the URI string in /etc/ldap.conf to point at ldap-server1, cron starts working. Both ldap-server1 and ldap-server2 are using running the same OS and kernel version (RHEL5) as well as the same version of 389 DS (389-ds-1.2.1-1.el5). Any ideas as to what could be causing this problem? Here is the /etc/ldap.conf on client1 if it matters: == begin /etc/ldap.conf === URI ldaps://ops-ldap006.svale.netledger.com:636 base dc=netsuite,dc=com timelimit 10 bind_policy soft nss_reconnect_tries 3 bind_timelimit 6 idle_timelimit 30 sudoers_base ou=SUDOers,dc=netsuite,dc=com sudoers_debug 0 ##ssl start_tls TLS_CACERT /etc/openldap/cacerts/ca.crt TLS_CACERTFILE /etc/openldap/cacerts/ca.crt TLS_REQCERT demand pam_lookup_policy yes pam_password exop nss_initgroups_ignoreusers root,named,avahi,haldaemon,dbus,gdm,postfix,puppet == end /etc/ldap.conf === Thanks in advance, David -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- Carsten Grzemba -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
