groups issues
by Alberto Viana
Hello,
I have the following scenario with multi master replication
389DS (389-Directory/1.3.2.13 B2014.066.1215) <-> AD (windows 2008R2)
I'm having the following problem using groups on 389:
What I DID
Create a user test1
Added this user to group GROUP_TEST
When I delete this user from 389DS via console or via windows, 389 DS does
not removes the group entry. On the windows side everything seems to be ok,
the user was deleted from the group too.
So the user test1 does not exists anymore, but in the group (on 389DS), I
still can see the entry:
uniqueMember: uid=test1,ou=GTI,dc=homolog,dc=rnp
10 years, 1 month
Disable tombstone
by carne_de_passaro
Hi,
In my environment, I don't need to deal ( basically recover deleted
entries) with the deleted entry.
Is there a way to disable the creation of the nstombstone entries on the
389-ds?
Regards
10 years, 1 month
How to add "dc=myExample,dc=com": Basic doubt
by Vimal Thomas
Hi,
I am new to 389 and LDAP in general.
I have 389 installed on my CentOS (389-ds-base-1.2.11.15-31.el6_5.x86_64)
I have the basic dc=example,dc=com created when I did server setup.
[*root@localhost vim]# ldapsearch -x -b "dc=example,dc=com" -s base*
*# extended LDIF*
*#*
*# LDAPv3*
*# base <dc=example,dc=com> with scope baseObject*
*# filter: (objectclass=*)*
*# requesting: ALL*
*#*
*# example.com <http://example.com>*
*dn: dc=example,dc=com*
*objectClass: top*
*objectClass: domain*
*dc: example*
*# search result*
*search: 2*
*result: 0 Success*
*# numResponses: 2*
*# numEntries: 1*
Now I am trying to create a new object on that line. I want to create
*dc=myExample,dc=com*
*[root@localhost vim]# ldapadd -f myExample.ldif -x -W*
*Enter LDAP Password: *
*adding new entry "dc=myExample,dc=com"*
*ldap_add: No such object (32)*
How can I create the entry *dc=myExample,dc=com?*
The content of myExample.ldif is as follows (similar to see what I saw in
search output of dc=example,dc=com ).
*dn: dc=myExample,dc=comobjectClass: topobjectClass: domaindc: myExample*
*Thanks,*
*Vimal*
10 years, 1 month
sasl/gssapi issue
by Robert Viduya
We're trying to get GSSAPI authentication working with 389 and following the doc page on the website, I think I've gotten it working a little too well.
We're using the stock ldapsearch command that comes with RHN, I believe it's from openldap. Here's a command log
$ kinit usera(a)PRISM.GATECH.EDU
Password for usera(a)PRISM.GATECH.EDU:
$ klist
Ticket cache: FILE:/tmp/krb5cc_651342_Bepfv28166
Default principal: usera(a)PRISM.GATECH.EDU
Valid starting Expires Service principal
03/06/14 16:55:07 03/07/14 16:55:07 krbtgt/PRISM.GATECH.EDU(a)PRISM.GATECH.EDU
$ ldapsearch -Y GSSAPI -H ldap://servera.iem.gatech.edu -LLL -b '' -s base 'objectclass=*' > /dev/null
SASL/GSSAPI authentication started
SASL username: usera(a)PRISM.GATECH.EDU
SASL SSF: 56
SASL data security layer installed.
$ ldapsearch -X userb(a)PRISM.GATECH.EDU -Y GSSAPI -H ldap://servera.iem.gatech.edu -LLL -b '' -s base 'objectclass=*' > /dev/null
SASL/GSSAPI authentication started
SASL username: userb(a)PRISM.GATECH.EDU
SASL SSF: 56
SASL data security layer installed.
and here's the relevant access log entries:
[06/Mar/2014:16:55:18 -0500] conn=1387 fd=64 slot=64 connection from 192.168.232.4 to 192.168.232.4
[06/Mar/2014:16:55:18 -0500] conn=1387 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI
[06/Mar/2014:16:55:18 -0500] conn=1387 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress
[06/Mar/2014:16:55:18 -0500] conn=1387 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI
[06/Mar/2014:16:55:18 -0500] conn=1387 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress
[06/Mar/2014:16:55:18 -0500] conn=1387 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI
[06/Mar/2014:16:55:18 -0500] conn=1387 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=usera,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu"
[06/Mar/2014:16:55:18 -0500] conn=1387 op=3 SRCH base="" scope=0 filter="(objectClass=*)" attrs=ALL
[06/Mar/2014:16:55:18 -0500] conn=1387 op=3 RESULT err=0 tag=101 nentries=1 etime=0
[06/Mar/2014:16:55:18 -0500] conn=1387 op=4 UNBIND
[06/Mar/2014:16:55:18 -0500] conn=1387 op=4 fd=64 closed - U1
[06/Mar/2014:16:55:25 -0500] conn=1388 fd=64 slot=64 connection from 192.168.232.4 to 192.168.232.4
[06/Mar/2014:16:55:25 -0500] conn=1388 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI
[06/Mar/2014:16:55:25 -0500] conn=1388 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress
[06/Mar/2014:16:55:25 -0500] conn=1388 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI
[06/Mar/2014:16:55:25 -0500] conn=1388 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress
[06/Mar/2014:16:55:25 -0500] conn=1388 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI
[06/Mar/2014:16:55:25 -0500] conn=1388 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=userb,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu"
[06/Mar/2014:16:55:25 -0500] conn=1388 op=3 SRCH base="" scope=0 filter="(objectClass=*)" attrs=ALL
[06/Mar/2014:16:55:25 -0500] conn=1388 op=3 RESULT err=0 tag=101 nentries=1 etime=0
[06/Mar/2014:16:55:25 -0500] conn=1388 op=4 UNBIND
[06/Mar/2014:16:55:25 -0500] conn=1388 op=4 fd=64 closed - U1
The issue is that if we do the ldapsearch without specifying an authzid (the "-X" option to ldapsearch), the bind correctly binds to DN that maps to the Kerberos principal name. However, if we specify an authzid that's different than what we kinitted to, the directory server binds to the DN that maps to that authzid even though we don't have the credentials for that user. It uses usera's credentials to bind to userb's DN.
My question is, is there a configuration setting somewhere that would make the directory server ignore any passed in authzid when using GSSAPI and just use what's in the credential cache?
10 years, 1 month
Local accounts vs 389 DS users
by Chaudhari, Rohit K.
I have a user that I have set locally on a Red Hat machine. I store that user in LDAP with the same Posix attributes, but their password differs. When I log in from the Red Hat machine, it uses the local cached credentials of that user (LDAP password and credentials never seem to matter). How can I synchronize the local and ldap version of the user so that I don't have to create it locally AND on LDAP on every single remote machine?
Thanks,
R
10 years, 1 month
Multi-Master Replication Issue
by Chaudhari, Rohit K.
Hi All,
I am trying to create multi-master replication in 389. But I am having
trouble using ldapmodify to create a replication manager DN account
I get the following error:
Additional info: TLS error -8157: Certificate extension not found
I went on the web and some people suggested I have a TLS_REQCERT=none line
in /etc/openldap/ldap.conf, but this did not fix it either.
My certificate in /etc/openldap/cacerts is called cacert.asc.
Does anyone know how I can fix my problem?
Thanks,
R
10 years, 1 month
Some bind DNs sporadically can't search users
by Morgan Jones
We're pulling our hair out over this issue and wondering if it rings a bell for anyone or perhaps there's a bug fix in a later version of 389 that might resolve it. I've looked and not found anything but it's also not the easiest issue to search for. We are on CentOS DS now but can move to 389 of course but hesitate to put forth the effort if we aren't reasonably sure it will resolve our issue.
Certain bind DNs (so far only service accounts) are unable to search for users. For instance:
[20/Feb/2014:10:18:05 -0500] conn=15600927 op=1 BIND dn="uid=copier,ou=employees,dc=domain,dc=org" method=128 version=3
[20/Feb/2014:10:18:05 -0500] conn=15600927 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=copier,ou=employees,dc=domain,dc=org"
[20/Feb/2014:10:18:05 -0500] conn=15600927 op=2 SRCH base="ou=employees,dc=domain,dc=org" scope=2 filter="(uid=user1)" attrs="cn mail uid"
[20/Feb/2014:10:18:05 -0500] conn=15600927 op=2 RESULT err=0 tag=101 nentries=0 etime=0
I did a search of the directory at the same time on the same replica as myself and other users with the same access level and was able to search uid=user1.
It sometimes only lasts a few minutes though in a few instances it was much longer. In one case we resolved it by adding a service account with a different name but the same access level and moved the application to that account. In another case where hundreds of copiers are configured with the binddn and thus changing the binddn wasn't practical we were able to resolve it by restoring the masters from a db2ldif and re-initializing the consumers. It's not isolated to once consumer--we've seen it on at least 2: one partial, one full.
Our environment is CentOS DS on CentOS 5. We have ~35,000 entries in the directory, most of them users. We only have 9 acis, most of which provide access via groups. We have 2 multi-masters, 2 full consumers and until recently 2 partial replicas. We converted the partial replicas to full replicas recently as we know there are/were issues with partial replication and wanted to rule that out. We're at the latest version of CentOS DS:
[morgan@ldap01 ~]$ rpm -qa|grep centos-ds
centos-ds-admin-8.2.1-1.el5.centos
centos-ds-console-8.2.0-4.el5.centos
centos-ds-base-8.2.8-2.el5.centos
centos-ds-8.2.0-2.el5.centos
[morgan@ldap01 ~]$
This issue is killing us as it effectively denies access to a service for all users that use it. This could be the VPN for instance which many users depend on all day for their work.
We are considering many options, primarily just moving to 389 on CentOS 6. That's a fairly big task for a site of our size so we'd like some confidence that we won't see a repeat of this issue. There's talk of considering other products which no one wants to do but we're all edgy as this has caused a fair amount of downtime and about all I can do at the moment is monitor for it and re-initialize when it happens which doesn't inspire confidence.
thank you,
-morgan
10 years, 1 month
intermittent issues with the DNA plugin
by Paul Robert Marino
I'm trying the DNA plugin for the first time based on the document
here http://directory.fedoraproject.org/wiki/Howto:DNA
usually it works well but occasionally it doesnt seem to work
correctly for GID numbers.
Ive noticed that if I add a user via the ldapadd command and set the following
"
uidNumber: 99999
gidNumber: 99999
"
the next value for the uidNumber and gidNumber is appropriately set
but occasionally the dnanextvalue for gidNumber fails to increment.
When this happens the next time I add a user the gid number get set to
the same value as the previous user I added. furthermore the
dnanextvalue doesn't increment again.
if I manually update the dnanextvalue for the gidNumber it will then
continue to work properly fro a time then eventually break down again.
I haven't seen any thing on the logs to indicate why this is happening
does any one have any pointers on what might cause this or how to debug it
further more I have a question Ive noticed that when the plugin
updates the value of dnanextvalue it only does it on the local server
not all of them is there any way to get these fields to replicate.
10 years, 1 month
Point to multiple LDAP servers
by Chaudhari, Rohit K.
Hello,
I want to configure authconfig-tui on Red Hat to point to multiple 389
servers (in case one went inaccessible, the clients would automatically
point to the 2nd or 3rd or 4th, etc. server).
1.How do I do this?
2.How would my /etc/hosts file look as a result of pointing to multiple
servers. Would I have to list each server as a separate line by IP
address?
Thanks,
Rohit
10 years, 1 month
