upgraded to latest 389, ldapsearch returns no results
by Brian High
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
12 years, 4 months
Clients can't use tls
by Ru-Benz Cáceres
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.
12 years, 4 months
Sync OU from Active Directory
by Walter Neu
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
12 years, 4 months
OU attribute in AD replication agreement
by Juan Asensio Sánchez
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.
12 years, 4 months
*;lang-en attributes in AD replication
by Juan Asensio Sánchez
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.
12 years, 4 months
