389-users August 2011

389-users@lists.fedoraproject.org

34 participants
27 discussions

Problem browsing LDAP with Outlook
by Chris Bryant 26 Aug '20

26 Aug '20

When configuring Microsoft Outlook (not Outlook Express) to access an LDAP directory, there is an option to 'Enable Browsing (requires server support)'. If this option is chosen and the directory server supports it, then you should be able to open the LDAP address book and page up and down through the results. I have been unable to get this working properly with 389 DS. When I try to browse from Outlook against the 389 DS directory, I am able to see the first page of results perfectly. However, if I move to the next page, only the first object returned will have any attributes included, and all of the rest of the objects in the page will have no attributes. I have a test perl script that duplicates this functionality as well. I can get this to work properly with an older version of Netscape Directory Server, and I can get it working with OpenDS. Since 389 DS advertises support for the controls that are required for this to work, just like the other two servers, then I would expect it to work there also. Has anyone out there gotten this to work with 389 DS? If so, can you share if there was anything special that you needed to do to get this to work? I'm trying to determine if this is a bug in the server, or if I'm just missing something in the configuration. Thanks, Chris USA.NET You Run Your Business. We'll Run Your Email. This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information of USA.NET, Inc. Any unauthorized review, use, copying, disclosure, or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply email and delete all copies of the original message.

3 2

Re: [389-users] Replication trouble when promoting dedicated Consumer to Multiple master [SOLVED]
by Roland Schwingel 20 Dec '11

20 Dec '11

Hi..... Finally I got it I don't know whether I did it the fully correct way, but it works now. I found that this mysterious replica id 3 was stored in dse.ldif of my server-b: To recap my scenario: server A < ----- server B <-----> server C -----> server D (dedicated Consumer) (multiple Master replica ID:1) (multiple Master replica ID:2) (Dedicated Consumer) I wanted to promote my server D to become a multiple master - but it did not work. What did I do to get it going: 1. Removed all replication agreements to/from server D. 2. Stopped all LDAP services on all servers (I was a little desperate) 3. Found replica id 3 in dse.ldif of server B(?) - nowhere else (why B and not C?) 4. Removed these bogus entries. 5. Restarted all LDAP services on all machines. 6. ldapsearch on server C still revealed the bogus replica id 3 (Where the heck is that cached?). 7. Reinitialized consumer server C from server B and restarted ldap on server C. 8. ldapsearch was clean by then. 9. removed my suffix on server D and removed changelog. 10. recreated suffix on server D and made server D a dedicated consumer 11. on server C created replication agreement to server D 12. initialized server D from server C. 13, Enabled changelog on server D 14. Changed server D to be Multiple Master with replica id 3 15, Created replication aggreement to server C from server D. 16. Worked. Restarted LDAP on server D and C. 17. Still works and replicates to all other machines along the path. 18. I need vacation.... Holy Moly! Roland __________________ Hi Reinhard, Thanks for your reply!! 389-users-bounces(a)lists.fedoraproject.org wrote on 14.07.2011 16:25:10: > From: Reinhard Nappert <rnappert(a)juniper.net> > To: "General discussion list for the 389 Directory server project." > <389-users(a)lists.fedoraproject.org> > Date: 14.07.2011 16:28 > Subject: Re: [389-users] Replication trouble when promoting > dedicated Consumer to Multiple master > Sent by: 389-users-bounces(a)lists.fedoraproject.org > > Do a ldapsearch -b 'nsuniqueid=ffffffff-ffffffff-ffffffff- > ffffffff,dc=mydomain,dc=com' -D <directory manager> -w <password> -s > base objectclass=nstombstone > > This gives you all the configured (history) of replication ids. The > following is the output in my setup. > > dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=base > objectClass: top > objectClass: nsTombstone > objectClass: extensibleobject > nsds50ruv: {replicageneration} 4df7a107000000010000 > nsds50ruv: {replica 1 ldap://yale:389} 4df7a396000000010000 4e19ad950000000100 > 00 > nsds50ruv: {replica 3 ldap://norquay:389} 4df7a39d000000030000 4e1605650000000 > 30000 > nsds50ruv: {replica 4 ldap://mustrum:389} 4df7a3a0000000040000 4dfb93650000000 > 40000 > nsds50ruv: {replica 2 ldap://louise:389} 4df7a39a000000020000 4e171a0700000002 > 0000 > o: base > nsruvReplicaLastModified: {replica 1 ldap://yale:389} 00000000 > nsruvReplicaLastModified: {replica 3 ldap://norquay:389} 00000000 > nsruvReplicaLastModified: {replica 4 ldap://mustrum:389} 00000000 > nsruvReplicaLastModified: {replica 2 ldap://louise:389} 00000000 > /\ > | > replication-id > I issued that command on my server Server C. I get the following results: # extended LDIF # # LDAPv3 # base <nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=mydomain,dc=com> with scope baseObject # filter: objectclass=nstombstone # requesting: ALL # # ffffffff-ffffffff-ffffffff-ffffffff, mydomain.com dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff, dc=mydomain,dc=com objectClass: top objectClass: nsTombstone objectClass: extensibleobject nsds50ruv: {replicageneration} 4bf162c6000000010000 nsds50ruv: {replica 2 ldap://server-c.mydomain.com:389} 4cd3fa1e00000002 0000 4e1ef45b000000020000 nsds50ruv: {replica 3 ldap://server-d.mydomain.de:389} nsds50ruv: {replica 1 ldap://server-b.mydomain.de:389} 4bf16732000000010 000 4e1ffa3e000000010000 dc: mydomain nsruvReplicaLastModified: {replica 2 ldap://server-c.mydomain.com:389} 4 e1ef445 nsruvReplicaLastModified: {replica 3 ldap://server-d.mydomain.de:389} 00000000 nsruvReplicaLastModified: {replica 1 ldap://server-b.mydomain.de:389} 4e 1ffa26 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 When I look at it I see that replica id 3 is assigned to my server-d (which should get that replica id). I started over deleted my server-d assigned it replica id 4 but nothing changes. I also cannot get rid of the informations for server-d in that nsuniqueid how can I do that? Thanks, Roland

2 1

Views, Filtered roles and CoS
by Colin Panisset 06 Oct '11

06 Oct '11

I have a pretty flat DIT, with all users currently under ou=people,dc=example,dc=com; these user objects also have posixAccount attributes, of which loginShell is one. What I'm trying to achieve is to be able to set a "default" loginShell to be a restricted shell (/bin/rbash) for developers, but allow that to be a non-restricted shell on systems which are development hosts. As an example, on a production host I'd like: $ ldapsearch -x "(uid=devuser)" uid loginshell to return: dn: cn=Dev User,ou=People,dc=example,dc=com loginShell: /bin/rbash uid: devuser while on a development host, I'd like the same search to return dn: cn=Dev User,ou=People,dc=example,dc=com loginShell: /bin/bash uid: devuser I thought I might be able to achieve this by creating a view called ou=Developers,dc=example,dc=com and using that as a base DN on the development boxes, then applying a CoS within the view to override the loginShell attribute, but then the CoS ends up being applied to the original entry too. Is there any way that I could: - have a CoS apply based on client system attributes, like IP address/hostname? - have a CoS which applies to a view that *doesn't* affect the original object? - perhaps make use of cosPriority through two different views, so as to have ou=Development,... and ou=Production,... (but that would be answered by the previous option anyway)? Is there some other clever way to achieve what I'd like? I'd really like to avoid maintaining 2 separate DITs for the same set of users. -- C.

3 6

Announcing 389 Directory Server version 1.2.9.6 Testing
by Rich Megginson 05 Sep '11

05 Sep '11

The 389 Project team is pleased to announce the release of 389-ds-base-1.2.9.6. This release has fixes for bugs found in 1.2.9 testing and bugs from earlier releases. NEW: EL6 support Beginning with RHEL 6.1, the 389-ds-base package is included in the base OS. It is the same as the upstream, except that it has no replication nor windows sync functionality. That has been split off into a new channel - Enterprise Identity Replication - and a new package - ds-replication. Therefore, the 389-ds-base package can no longer be provided via EPEL, due to RHEL/EPEL packaging restrictions. However, the 389 Project will still make the full 389-ds-base package, including replication/winsync, available via http://repos.fedorapeople.org/repos/rmeggins/389-ds-base. See http://directory.fedoraproject.org/wiki/Download for more information. Installation yum install --enablerepo=updates-testing 389-ds # or for EPEL yum install --enablerepo=epel-testing [--enablerepo=epel-testing-389-ds-base] 389-ds setup-ds-admin.pl Upgrade yum upgrade --enablerepo=updates-testing 389-ds-base idm-console-framework 389-admin 389-ds-console 389-admin-console # or for EPEL yum upgrade --enablerepo=epel-testing [--enablerepo=epel-testing-389-ds-base] 389-ds-base idm-console-framework 389-admin 389-ds-console 389-admin-console setup-ds-admin.pl -u How to Give Feedback The best way to provide feedback is via the Fedora Update system. * Go to https://admin.fedoraproject.org/updates * In the Search box in the upper right hand corner, type in the name of the package * In the list, find the version and release you are using (if you're not sure, use rpm -qi <package name> on your system) and click on the release * On the page for the update, scroll down to "Add a comment" and provide your input Or just send us an email to 389-users(a)lists.fedoraproject.org Reporting Bugs If you find a bug, or would like to see a new feature, you can enter it here - https://bugzilla.redhat.com/enter_bug.cgi?product=389 More Information * Release Notes - http://port389.org/wiki/Release_Notes * Install_Guide - http://port389.org/wiki/Install_Guide * Download - http://port389.org/wiki/Download

2 15

Re: [389-users] Setting up multi master replication error 81
by David Hoskinson 01 Sep '11

01 Sep '11

I was able to run this command on both machines with similar results. From server A I pointed the script at server A fqdn and server b fqdn and returned results. I then did the same thing on server b with both fqdn. It seems to me from what I am seeing is that the protocols are supported and correct and there is a possible "trust" issue going on here? [root@xxx ~]# /usr/lib64/mozldap/ldapsearch -h xxx.stag.cle.us -ZZZ -P /etc/dirsrv/slapd-xxx/cert8.db -s base -b "" "objectclass=*" version: 1 dn: objectClass: top namingContexts: dc=stag,dc=cle,dc=us supportedExtension: 2.16.840.1.113730.3.5.7 supportedExtension: 2.16.840.1.113730.3.5.8 supportedExtension: 2.16.840.1.113730.3.5.10 supportedExtension: 2.16.840.1.113730.3.5.3 supportedExtension: 2.16.840.1.113730.3.5.12 supportedExtension: 2.16.840.1.113730.3.5.5 supportedExtension: 2.16.840.1.113730.3.5.6 supportedExtension: 2.16.840.1.113730.3.5.9 supportedExtension: 2.16.840.1.113730.3.5.4 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 2.16.840.1.113730.3.4.3 supportedControl: 2.16.840.1.113730.3.4.4 supportedControl: 2.16.840.1.113730.3.4.5 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.16 supportedControl: 2.16.840.1.113730.3.4.15 supportedControl: 2.16.840.1.113730.3.4.17 supportedControl: 2.16.840.1.113730.3.4.19 supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.4.14 supportedControl: 2.16.840.1.113730.3.4.20 supportedControl: 1.3.6.1.4.1.1466.29539.12 supportedControl: 2.16.840.1.113730.3.4.12 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.13 supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: PLAIN supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: LOGIN supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: ANONYMOUS supportedSASLMechanisms: DIGEST-MD5 supportedLDAPVersion: 2 supportedLDAPVersion: 3 vendorName: 389 Project vendorVersion: 389-Directory/1.2.8.3 B2011.122.1636 dataversion: 020110831163410 netscapemdsuffix: cn=ldap://dc=xxx,dc=stag,dc=cle,dc=us:389 David Hoskinson | DATATRAK International Systems Engineer Mayfield Heights, Ohio, USA +1.440.443.0082 x 124 (p) | +1.216.280.5457 (m) david.hoskinson(a)datatrak.net<mailto:david.hoskinson@datatrak.net> | www.datatrak.net<http://www.datatrak.net/>

2 9

Re: [389-users] Setting up multi master replication error 81
by David Hoskinson 31 Aug '11

31 Aug '11

I hope I have replied correctly this time. Yes I created the certs on both machines using this link: http://xilab.net/blog/389-directory-server-ssl walking through each step one at a time. As you see I created a Server-Cert and the serial number 1000,1001,1002 for both servers. I can understand if I should have put 1000,1001,1002 for 1 machine and 1100,1101,1102 for other machine. I followed the instructions on the link you sent me to delete existing cert and replace with my new one for server b which was exported from server a. This time I did not receive error messages when importing, however I still get the message 81 can't contact ldap server. Hope this information helps helps me understand how this works better as this is the last step. On 08/31/2011 09:12 AM, David Hoskinson wrote: This seems to be getting me somewhere.... Thanks for the quick response .... I have run the following commands on the master $ certutil -S -n "consumer-Cert" -s "cn=xxx.stag.cle.us" -c "CA certificate" -t "u,u,u" -m 999 -v 120 -d . -k rsa Do you have another cert (server cert or ca cert) with the same -m value? The value given to the -m argument must be unique for every cert. $ pk12util -d . -o consumer-cert.p12 -n Server-Cert And then copied consumer.p12 and cacert.asc to /tmp on server B When I tried to import the replication consumer cert into other 389 DS I receive the following error [root@xxx302 slapd-adm302]# pk12util -d . -i /tmp/consumer-cert.p12 Enter Password or Pin for "NSS Certificate DB": Enter Password or Pin for "NSS Certificate DB": Enter password for PKCS12 file: pk12util: using nickname: xxx.stag.cle.us pk12util: PKCS12 decode import bags failed: You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert. From: Rich Megginson [mailto:rmeggins@redhat.com] Sent: Wednesday, August 31, 2011 10:51 AM To: General discussion list for the 389 Directory server project. Cc: David Hoskinson Subject: Re: [389-users] Setting up multi master replication error 81 On 08/31/2011 08:45 AM, David Hoskinson wrote: I have setup 2 servers running the following versions of 389 Directory server 389-adminutil-1.1.13-1.el5 389-admin-1.1.16-1.el5 389-dsgw-1.1.6-1.el5 389-ds-1.2.1-1.el5 389-ds-base-1.2.8.3-1.el5 389-admin-console-1.1.7-1.el5 389-console-1.1.4-1.el5 389-admin-console-doc-1.1.7-1.el5 389-ds-base-libs-1.2.8.3-1.el5 389-ds-console-1.2.5-1.el5 389-ds-console-doc-1.2.5-1.el5 I have also enabled ssl and created the appropriate certs for each machine. I am able to set each machine as a client so I can test that from server A, I can login to server A while being authenticated by server B and vice versa. The last problem that I seem to be having is setting up replication. I have enabled the changelog, created a replication account, and enabled replica. When I create my replication agreement on the userRoot, the supplier shows as server A port 389 and the consumer shows as server B 636. I am using Use TLS with ldaps, and simple bind with my replication account and password. I next leave enable fractional replication unchecked, always keep directories in sync and initialize consumer... this is on server A and done. I get the following error message. Consumer initialization has unsuccessfully completed. The error received by the replica is '81 - LDAP error: Can't contact LDAP server' I believe I am reading that in some manner the cacert.asc from server A has to be on server B and the cacert B has to be on server A Correct. http://directory.fedoraproject.org/wiki/Howto:SSL#Exporting_the_certs_for_u… but am not sure and having problems with this. Any help with this would be appreciated and can provide additional information if needed... David Hoskinson | DATATRAK International Systems Engineer Mayfield Heights, Ohio, USA +1.440.443.0082 x 124 (p) | +1.319.471.3689 (m) david.hoskinson(a)datatrak.net<mailto:david.hoskinson@datatrak.net> | www.datatrak.net<http://www.datatrak.net/> -- 389 users mailing list 389-users(a)lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/389-users David Hoskinson | DATATRAK International Systems Engineer Mayfield Heights, Ohio, USA +1.440.443.0082 x 124 (p) | +1.319.471.3689 (m) david.hoskinson(a)datatrak.net<mailto:david.hoskinson@datatrak.net> | www.datatrak.net<http://www.datatrak.net/>

2 1

Setting up multi master replication error 81
by David Hoskinson 31 Aug '11

31 Aug '11

I have setup 2 servers running the following versions of 389 Directory server 389-adminutil-1.1.13-1.el5 389-admin-1.1.16-1.el5 389-dsgw-1.1.6-1.el5 389-ds-1.2.1-1.el5 389-ds-base-1.2.8.3-1.el5 389-admin-console-1.1.7-1.el5 389-console-1.1.4-1.el5 389-admin-console-doc-1.1.7-1.el5 389-ds-base-libs-1.2.8.3-1.el5 389-ds-console-1.2.5-1.el5 389-ds-console-doc-1.2.5-1.el5 I have also enabled ssl and created the appropriate certs for each machine. I am able to set each machine as a client so I can test that from server A, I can login to server A while being authenticated by server B and vice versa. The last problem that I seem to be having is setting up replication. I have enabled the changelog, created a replication account, and enabled replica. When I create my replication agreement on the userRoot, the supplier shows as server A port 389 and the consumer shows as server B 636. I am using Use TLS with ldaps, and simple bind with my replication account and password. I next leave enable fractional replication unchecked, always keep directories in sync and initialize consumer... this is on server A and done. I get the following error message. Consumer initialization has unsuccessfully completed. The error received by the replica is '81 - LDAP error: Can't contact LDAP server' I believe I am reading that in some manner the cacert.asc from server A has to be on server B and the cacert B has to be on server A but am not sure and having problems with this. Any help with this would be appreciated and can provide additional information if needed... David Hoskinson | DATATRAK International Systems Engineer Mayfield Heights, Ohio, USA +1.440.443.0082 x 124 (p) | +1.319.471.3689 (m) david.hoskinson(a)datatrak.net<mailto:david.hoskinson@datatrak.net> | www.datatrak.net<http://www.datatrak.net/>

2 1

PAM Pass Through- PAM succeeds but 389 fails?
by Sam Harmon 30 Aug '11

30 Aug '11

Hello, I'm trying to configure a 389 instance to pass authentication to our Kerberos server using the PAM Pass Through plugin. As far as I can tell, the authentication is happening correctly in PAM, but it's getting refused by the 389 server. I've included the relevant configurations and some log file snippets of an example authentication. Has anyone seen a problem like this before? Do I have a problem in my configuration? Thanks, Sam My pass through auth config from dse.ldif: dn: cn=PAM Pass Through Auth,cn=plugins,cn=config objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject objectClass: pamConfig cn: PAM Pass Through Auth nsslapd-pluginPath: libpam-passthru-plugin nsslapd-pluginInitfunc: pam_passthruauth_init nsslapd-pluginType: preoperation nsslapd-pluginEnabled: on nsslapd-pluginloadglobal: true nsslapd-plugin-depends-on-type: database pamMissingSuffix: ALLOW pamIncludeSuffix: o=isp pamExcludeSuffix: cn=config pamIDMapMethod: RDN pamIDAttr: notUsedWithRDNMethod pamFallback: TRUE pamSecure: FALSE pamService: ldapserver nsslapd-pluginId: pam_passthruauth nsslapd-pluginVersion: 1.2.2 nsslapd-pluginVendor: 389 Project nsslapd-pluginDescription: PAM pass through authentication plugin Here is the PAM configuration file I'm using (/etc/pam.d/ldapserver): auth sufficient /lib64/security/pam_krb5.so force_first_pass forwardable debug no_user_check ignore_k5login no_initial_prompt password sufficient /lib64/security/pam_krb5.so use_authtok session optional /lib64/security/pam_krb5.so Here's the PAM log from an attempted authentication: Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: configured realm 'INS.CWRU.EDU' Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: flags: forwardable Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: flag: no ignore_afs Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: flag: no krb4_convert Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: flag: krb4_convert_524 Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: flag: krb4_use_as_req Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: will try previously set password first Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: will let libkrb5 ask questions Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: flag: no use_shmem Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: flag: no external Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: flag: no multiple_ccaches Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: flag: validate Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: flag: warn Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: ticket lifetime: 0 Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: renewable lifetime: 0 Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: banner: Kerberos 5 Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: ccache dir: /tmp Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: keytab: FILE:/etc/krb5.keytab Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: called to authenticate 'sdh7', realm 'INS.CWRU.EDU' Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: authenticating 'sdh7(a)INS.CWRU.EDU' Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: not using an entered password for 'sdh7', allowing libkrb5 to prompt for more Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: authenticating 'sdh7(a)INS.CWRU.EDU' to 'krbtgt/INS.CWRU.EDU(a)INS.CWRU.EDU' Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: libkrb5 asked for long-term password, replacing prompt text with generic prompt Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: krb5_get_init_creds_password(krbtgt/INS.CWRU.EDU(a)INS.CWRU.EDU) returned 0 (Success) Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: validating credentials Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: error reading keytab 'FILE:/etc/krb5.keytab' Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: TGT verified Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: got result 0 (Success) Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: authentication succeeds for 'sdh7' (sdh7(a)INS.CWRU.EDU) Aug 30 12:55:44 its-srv-ksl-1 ns-slapd: pam_krb5[23742]: pam_authenticate returning 0 (Success) And here is the 389 error log from the same auth: [30/Aug/2011:12:55:44 -0400] pam_passthru-plugin - => pam_passthru_bindpreop [30/Aug/2011:12:55:44 -0400] pam_passthru-plugin - pam msg [0] = 1 Password: [30/Aug/2011:12:55:44 -0400] pam_passthru-plugin - Error from PAM during pam_acct_mgmt (7: Authentication failure) [30/Aug/2011:12:55:44 -0400] pam_passthru-plugin - Invalid PAM password for user id [sdh7], bind DN [uid=sdh7,ou=pe ople,o=cwru.edu,o=isp][30/Aug/2011:12:55:44 -0400] pam_passthru-plugin - <= handled (error 49 - Invalid credentials) [30/Aug/2011:12:55:44 -0400] passthru-plugin - => passthru_bindpreop[30/Aug/2011:12:55:44 -0400] passthru-plugin - <= not handled (not one of our suffixes)

3 3

force MAC LDAP client to comply Linux LDAP server's password policy
by Shouben Zhou 29 Aug '11

29 Aug '11

Does anybody how to configure MAC OS LDAP client to comply the password policy (expiration time) against Linux LDAP server? -- -- Shouben Zhou Science Systems and Applications Inc.(SSAI) 1 Enterprise Pkwy, Hampton, VA 23666 Tel: (757)951-1905 Fax: (757)951-1900 Email: Shouben.Zhou(a)nasa.gov

1 0

too many fds open
by Martin Stiborský 26 Aug '11

26 Aug '11

Hello, I'd like to ask you here for help with problem with 389 Fedora LDAP. Our LDAP fail every day, because of "too many fds open" problem, as is logged in log file… I've found many posts about it on internet (this is one seems to be useful http://www.linuxquestions.org/questions/linux-enterprise-47/fedora-director…), but still the problem is there even after raise of few limits. When the ldap failed, I checked number of created "fd" by dirsrv process with ls -l /proc/$DIRSRV_PID/fd | wc -l and it was about ~1000 files, so probably some limit in system is still in use (fds per process or user??). Please, could you give me a hint? Thanks a lot! -- S pozdravem Martin Stiborský Jabber: stibi(a)njs.netlab.cz

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users August 2011