389-users December 2011

389-users@lists.fedoraproject.org

20 participants
26 discussions

upgraded to latest 389, ldapsearch returns no results
by Brian High 07 Dec '11

07 Dec '11

Hi 389-users, Perhaps you can help solve a mystery for me. I just upgraded 389 Directory on RHEL5, 64bit from 389-ds-base 1.2.2 to 1.2.9.9. yum --enablerepo=epel upgrade setup-ds-admin.pl -u ... as prescribed in the release notes: http://directory.fedoraproject.org/wiki/Release_Notes Here is the problem. I used to be able to query using ldapsearch like this (anonymous bind): ldapsearch -x -ZZ -h <HOST> -b <BASE> -LLL "(uid=<USER>)" gecos And I would see: dn: uid=<USER>,<BASE> gecos: System User Now, after the upgrade, this returns no results and no errors, but if I bind like this (authenticated bind), then it works _fine_: ldapsearch -x -ZZ -D "cn=directory manager" -W -h <HOST> -b <BASE> -LLL "(uid=<USER>)" gecos Here is some log output showing the anon. bind search and the non-anon. bind search (sanitized): [07/Dec/2011:14:52:14 -0800] conn=120 SSL 256-bit AES [07/Dec/2011:14:52:14 -0800] conn=120 op=1 BIND dn="" method=128 version=3 [07/Dec/2011:14:52:14 -0800] conn=120 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="" [07/Dec/2011:14:52:14 -0800] conn=120 op=2 SRCH base="dc=EXAMPLE,dc=COM" scope=2 filter="(uid=USERNAME)" attrs="gecos" [07/Dec/2011:14:52:14 -0800] conn=120 op=2 RESULT err=0 tag=101 nentries=0 etime=0 [07/Dec/2011:14:52:14 -0800] conn=120 op=3 UNBIND [07/Dec/2011:14:52:14 -0800] conn=120 op=3 fd=71 closed - U1 [07/Dec/2011:14:53:37 -0800] conn=121 SSL 256-bit AES [07/Dec/2011:14:53:40 -0800] conn=121 op=2 BIND dn="cn=directory manager" method=128 version=3 [07/Dec/2011:14:53:40 -0800] conn=121 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [07/Dec/2011:14:53:40 -0800] conn=121 op=3 SRCH base="dc=EXAMPLE,dc=COM" scope=2 filter="(uid=USERNAME)" attrs="gecos" [07/Dec/2011:14:53:40 -0800] conn=121 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [07/Dec/2011:14:53:40 -0800] conn=121 op=4 UNBIND [07/Dec/2011:14:53:40 -0800] conn=121 op=4 fd=71 closed - U1 The only difference I can see is the nentries=1 in the latter test. So, I looked into the latest features and see there are some more nsslapd-anonlimitsdn: nsslapd-allow-anonymous-access: on ... which I have left as defaults. It looks like anonymous binds should still work. So, I am wondering, why do anonymous binds no longer return results? --Brian

1 0

Clients can't use tls
by Ru-Benz Cáceres 06 Dec '11

06 Dec '11

In my server tls works fine for my clients, problems are when I try to active on the others clients machine. I import the certificate just like I did in my server. But I have problems when I activate tls. At the begin it works fine but minutes later I check the logs and I get this: Dec 6 15:06:52 192.168.4.21 id: nss-ldap: do_open: do_start_tls failed:stat=-1 Dec 6 15:06:52 192.168.4.21 id: nss_ldap: reconnecting to LDAP server (sleeping 64 seconds)... Dec 6 15:08:14 192.168.4.21 id: nss-ldap: do_open: do_start_tls failed:stat=-1 Dec 6 15:08:32 192.168.4.21 id: nss_ldap: could not search LDAP server - Server is unavailable Somebody can help me? Thanks.

2 1

Master/Slave Replication setup via command line
by John Mancuso 06 Dec '11

06 Dec '11

Any way to setup Master/Slave Replication setup via command line? The java GUI is a bit of a pain to use but those are the only instructions I see. Thanks! -John

4 4

Sync OU from Active Directory
by Walter Neu 05 Dec '11

05 Dec '11

Hi, is it possible to sync a complete LDAP tree from an Active Directory or only user and group entries? My problem is, that I have to build the complete tree from our AD server on my 389ds to sync the user entries, because OUs are not synced. Thanks in advance

3 2

OU attribute in AD replication agreement
by Juan Asensio Sánchez 05 Dec '11

05 Dec '11

Hi I continue trying to replicate the users from the 389 directory to an AD server. After removing language subtype attributes, I get now this error when a user contains an "ou" attribute: [01/Dec/2011:13:50:04 +0100] NSMMReplicationPlugin - agmt="cn=ll" (XXXX:636): windows_process_total_entry: Looking dn="uid=XXXX,ou=People,o=XXXX,dc=XXXX,dc=XXXX" (ours) [01/Dec/2011:13:50:04 +0100] NSMMReplicationPlugin - agmt="cn=ll" (XXXX:636): map_entry_dn_outbound: looking for AD entry for DS dn="uid=XXXX,ou=People,o=XXXX,dc=XXXX,dc=XXXX" guid="a76de75aca5cc74ca5425d4d7435797a" [01/Dec/2011:13:50:04 +0100] NSMMReplicationPlugin - agmt="cn=ll" (XXXX:636): map_entry_dn_outbound: looking for AD entry for DS dn="uid=XXXX,ou=People,o=XXXX,dc=XXXX,dc=XXXX" username="XXXX" [01/Dec/2011:13:50:04 +0100] - Calling windows entry search request plugin [01/Dec/2011:13:50:04 +0100] - windows_search_entry: recieved 1 messages, 0 entries, 0 references [01/Dec/2011:13:50:04 +0100] NSMMReplicationPlugin - agmt="cn=ll" (XXXX:636): map_entry_dn_outbound: entry not found - rc 0 [01/Dec/2011:13:50:04 +0100] - Windows sync entry: Created new remote entry: dn:: XXXX objectClass: top objectClass: person objectClass: organizationalperson objectClass: user userprincipalname: XXXX(a)pruebas.local st: XXXX postalCode: XXXX postalAddress:: XXXX streetAddress:: XXXX facsimileTelephoneNumber: XXXX telephoneNumber: XXXX mail: XXXX o: XXXX l: XXXX ou: XXXX givenName: XXXX sn:: XXXX cn:: XXXX sAMAccountName: XXXX accountExpires: 0 codePage: 0 [01/Dec/2011:13:50:04 +0100] - Attempting to add entry cn=XXXX,ou=LDAPPeople,dc=pruebas,dc=local to AD for local entry uid=XXXX,ou=XXXX,o=XXXX,dc=XXXX,dc=XXXX [01/Dec/2011:13:50:04 +0100] NSMMReplicationPlugin - agmt="cn=ll" (XXXX:636): Received error [00002082: AtrErr: DSID-03151145, #1: 0: 00002082: DSID-03151145, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att b (ou):len 262 ] when attempting to add entry [cn=XXXX,ou=LDAPPeople,dc=pruebas,dc=local]: Please correct the attribute specified in the error message. Refer to the Windows Active Directory docs for more information. After googling testing, i realized that the attribute "ou" in AD is limited to 64 chars, when the values of that attribute in our directory are larger. Perhaps, this could be avoided excluding the attribute from the agreement, nut nowadays that is not possible. So the only solution I have is to modify the schema of AD so that attribute could hold larger values; but I have not found any solution for this. Anyone does know how to do this? Thanks in advance.

1 1

*;lang-en attributes in AD replication
by Juan Asensio Sánchez 01 Dec '11

01 Dec '11

Hi In our directory, we have some users with attributes like cn;lang-en, sn;lang-en, with the same value than cn or sn, but without tildes (á, è) or "ñ". When I try to synchronize these users with Active Directory, I get this error: [30/Nov/2011:11:58:32 +0100] - Windows sync entry: Created new remote entry: dn:: XXXXXXX objectClass: top objectClass: person objectClass: organizationalperson objectClass: user userprincipalname: XXXXXXX(a)pruebas.local st: XXXXXXX postalCode: XXXXXXX postalAddress:: XXXXXXX streetAddress:: XXXXXXX facsimileTelephoneNumber: XXXXXXX telephoneNumber: XXXXXXX mail: XXXXXXX o: XXXXXXX l: XXXXXXX ou: XXXXXXX givenName: XXXXXXX sn:: XXXXXXX cn:: XXXXXXX sAMAccountName: XXXXXXX accountExpires: 0 codePage: 0 sn;lang-en: XXXXXXX [30/Nov/2011:11:58:32 +0100] - Attempting to add entry cn=XXXXXXX,ou=LDAPPeople,dc=pruebas,dc=local to AD for local entry uid=XXXXXXX,ou=People,o=XXXXXXX,dc=XXXXXXX,dc=XXXXXXX [30/Nov/2011:11:58:32 +0100] NSMMReplicationPlugin - agmt="cn=ll" (XXXXXXX:636): Received result code 16 (00000057: LdapErr: DSID-0C090B38, comment: Error in attribute conversion operation, data 0, vece) for add operation If I remove the attribute "sn;lang-en", the sync works ok (well, not, but that is another story). Can I make the sync agreement exclude some attributes, like a normal agreement? Thanks in advance.

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users December 2011