389-users February 2010

389-users@lists.fedoraproject.org

40 participants
48 discussions

Re: [389-users] With LDAP server stopped, local authentication fails...
by Tom Lanyon 11 Feb '10

11 Feb '10

On 05/02/2010, at 3:16 AM, Sean Carolan wrote: >> What is listed in your /etc/nsswitch.conf for passwd, shadow and group? > > Here's what I have on one of the clients: > > passwd: files ldap > shadow: files ldap > group: files ldap > >> If you do not have an entry for 'files' then the local /etc/{passwd,shadow,group} files will not be searched. > > Should it not try "files" first? I'm still seeing that when the LDAP > server is down, I can't log onto the client machines at all. Logging > in as root works, but logging in as a normal user doesn't. Any > suggestions? Yes, it should... This may be a silly question, but -- if you remove/disable the LDAP config, can you log in with the local account?

4 13

(no subject)
by Theodotos Andreou 11 Feb '10

11 Feb '10

Guys I' ve seen this warning on the 8.1 Administration Guide: WARNING There can only be a single sync agreement between the Directory Server environment and the Active Directory environment. Multiple sync agreements to the same Active Directory domain can create entry conflicts. Ref: http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Windows_Sync.html In my scenario I have many OUs under the AD synchronized subtree eg ou=dep1,dc=example,dc=com , ou=dep2,dc=example,dc=com , etc. I tried to synchronize the whole subtree dc=example,dc=com to the respective tree on DS but this fails due to schema incompatibilities. So I created one sync agreement per OU and it seems to be working as expected in my test environment. What that warning above is all about? What could possibly go wrong if you use multiple sync agreements. How can there be entry conflicts if each synchronized subtree is different from the other? Another issue I have is that when users are disabled on the AD they are still active on the DS. An obvious workaround is to change the password of the disabled user so he can not use his account on AD but it would be nice if their is a solution to avoid this. Any ideas?

1 0

With LDAP server stopped, local authentication fails...
by Andrew Commons 10 Feb '10

10 Feb '10

I am led to believe that editing /etc/ldap.conf and uncommenting the bind_policy line and changing it to: bind_policy soft solves this problem (with a sledge hammer). I will be trying it shortly after I've diagnosed another problem (in fact I found it while looking for clues to another problem), but be my guest and try it first, just let the list (and me) know how it works out :-) Cheers, Andrew

1 0

Re: [389-users] memberOf problem
by Moises Barba Perez 09 Feb '10

09 Feb '10

Hi, Platform: CentOs 5.4 389-ds- base version: 389-ds-base-1.2.4-1.el5 dc=test,dc=local - o=o1 - ou=People - uid=U11 - uid=U12 - ou=Groups - cn=G11 - cn=G12 - o=o2 - ou=People - uid=U21 - uid=U22 - ou=Groups - cn=G21 - cn=G22 Simplifying, we have four servers, for two different databases. Each two are multimaster of their own replica, and hub of the other replica (configured as return referrals for update operations). In Suffix1 (database1) there are users U11 and U12, and groups G11 and G12. In Suffix2 (database2) there are users U21 and U22, and groups G21 and G22. If I add U11 to G11 from master servers of database1, the attribute memberOf is generated in U11, but if I add U21 to group U11, the attribute memberOf is not generated in the user U21, as the database of the user is configured as return referrals for update. Thanks. Moisés. > > ---------- Forwarded message ---------- > From: Rich Megginson <rmeggins(a)redhat.com> > Date: 2010/2/8 > Subject: Re: [389-users] memberOf problem > To: "General discussion list for the 389 Directory server project." < > 389-users(a)lists.fedoraproject.org> > > > > Moises Barba Perez wrote: > > Hi, > > > > I need some help with a replication problem an memberof plugin, hope > > somebody can. > > > > The problem arrives when we try to modify a group with users from > > another organization because that database is read only > > (specifications of our directory), and the memberOf plugin can't write > > on it. > > > > How can I have the attribute memberOf in all users of all > > organizations without dependence of its organization in multimaster mode? > What is your platform and 389-ds-base version? Can you be more specific > about your tree structure and entries? LDIF excerpts would be helpful. > > > > Thanks. > > Moises. > > ------------------------------------------------------------------------ > > > > -- > > 389 users mailing list > > 389-users(a)lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > -- > 389 users mailing list > 389-users(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users > >

1 0

Replica fails
by jean-Noël Chardron 09 Feb '10

09 Feb '10

Hello, I tried to setup a replica in single master from a supplier to a consumer So I created a new 389 server with setup-ds-admin.pl called briand and I follow the guide http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Managing_Replicatio… The supplier is a fedora 11 x86_64 , Directory server version 1.2.2 (name = aragon) The consumer is a Centos 5.4 fresh install x86_64 , Directory server 1.2.4 (name=briand) I get an error when I initialize the consumer from the console of the supplier : no such replica code error 6 follow the error log : On the Supplier : [09/Feb/2010:09:35:36 +0100] NSMMReplicationPlugin - agmt="cn=briand ad" (briand:389): Beginning linger on the connection [09/Feb/2010:09:35:36 +0100] NSMMReplicationPlugin - agmt="cn=briand ad" (briand:389): No linger to cancel on the connection [09/Feb/2010:09:35:36 +0100] NSMMReplicationPlugin - agmt="cn=briand ad" (briand:389): Disconnected from the consumer [09/Feb/2010:09:35:36 +0100] NSMMReplicationPlugin - agmt="cn=briand ad" (briand:389): State: start -> ready_to_acquire_replica [09/Feb/2010:09:35:36 +0100] NSMMReplicationPlugin - agmt="cn=briand ad" (briand:389): Trying non-secure slapi_ldap_init_ext [09/Feb/2010:09:35:36 +0100] NSMMReplicationPlugin - agmt="cn=briand ad" (briand:389): binddn = cn=replication manager,cn=config, passwd = {DES}---------CUT------------== [09/Feb/2010:09:35:36 +0100] NSMMReplicationPlugin - agmt="cn=briand ad" (briand:389): No linger to cancel on the connection [09/Feb/2010:09:35:36 +0100] NSMMReplicationPlugin - agmt="cn=briand ad" (briand:389): Unable to acquire replica: there is no replicated area "dc=ad,dc=dr15,dc=cnrs,dc=fr" on the consumer server. Replication is aborting. [09/Feb/2010:09:35:36 +0100] NSMMReplicationPlugin - agmt="cn=briand ad" (briand:389): Beginning linger on the connection [09/Feb/2010:09:35:36 +0100] NSMMReplicationPlugin - agmt="cn=briand ad" (briand:389): State: ready_to_acquire_replica -> stop_fatal_error [09/Feb/2010:09:35:36 +0100] NSMMReplicationPlugin - agmt="cn=briand ad" (briand:389): Incremental update failed and requires administrator action [09/Feb/2010:09:35:36 +0100] NSMMReplicationPlugin - agmt="cn=briand ad" (briand:389): State: stop_fatal_error -> stop_fatal_error [09/Feb/2010:09:36:37 +0100] NSMMReplicationPlugin - agmt="cn=briand ad" (briand:389): Linger timeout has expired on the connection [09/Feb/2010:09:36:37 +0100] NSMMReplicationPlugin - agmt="cn=briand ad" (briand:389): Disconnected from the consumer [09/Feb/2010:09:36:37 +0100] NSMMReplicationPlugin - agmt="cn=briand ad" (briand:389): Linger timeout has expired on the connection [09/Feb/2010:09:36:37 +0100] NSMMReplicationPlugin - agmt="cn=briand ad" (briand:389): Disconnected from the consumer On the consumer : [02/Sep/2010:09:43:27 +0200] NSMMReplicationPlugin - conn=53 op=3 replica="unknown": Unable to acquire replica: error: no such replica Any help is welcome Thanks, -- Jean-Noel Chardron

1 0

memberOf problem
by Moises Barba Perez 08 Feb '10

08 Feb '10

Hi, I need some help with a replication problem an memberof plugin, hope somebody can. The problem arrives when we try to modify a group with users from another organization because that database is read only (specifications of our directory), and the memberOf plugin can't write on it. How can I have the attribute memberOf in all users of all organizations without dependence of its organization in multimaster mode? Thanks. Moises.

2 1

id2entry.db4 very large
by Giovanni Mancuso 08 Feb '10

08 Feb '10

Hi, i have in my Directory Server the id2entry.db4 file that is 9,8GB: # ls -hl id2entry.db4 -rw------- 1 nobody nobody 9.8G Feb 8 15:11 id2entry.db4 But in my ldap i have only 33 entry: # ldapsearch -T -vvv -H ldaps://127.0.0.1 -x -Z -b "o=addressbook1"|grep -ri dn |wc -l 33 I previously had more entries in my DS but now i delete all entries... Is not id2entry.db4 cleaned automatically? Can i clean it manually? Thanks

4 3

The same error but with the 389-console
by Serge.Sterck＠fmsb.be 08 Feb '10

08 Feb '10

2 1

389 DS chrashes in case someone enters wrong password
by Kurzmann Birgit 08 Feb '10

08 Feb '10

Hi! We are using 389 DS and PAM to pass authentication to active directory. It works fine until someone tries to authenticate with a wrong password. In that case 389 directory server crashes. /log/secure looks like this: Feb 5 12:31:42 st39ldap01 ns-slapd: pam_krb5[12937]: authentication fails for 'k.thormann' (k.thormann(a)ST.REDCROSS.OR.AT): Authentication failure (Cannot read password) Feb 5 12:31:42 st39ldap01 ns-slapd: pam_unix(ldapserver:auth): authentication failure; logname= uid=500 euid=500 tty= ruser= rhost= user=k.thormann Feb 5 12:31:43 st39ldap01 ns-slapd: pam_krb5[12937]: authentication fails for 'k.thormann' (k.thormann(a)ST.REDCROSS.OR.AT): Authentication failure (Looping detected inside krb5_get_in_tkt) PAM File looks like this: auth sufficient pam_krb5.so use_first_pass forwardable auth include system-auth account [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore authinfo_unavail=ignore] pam_krb5.so account include system-auth password include system-auth password sufficient pam_krb5.so use_authtok session optional pam_krb5.so Any idea how we can fix this problem? Cheers, Birgit

3 2

migration from tivoli ldap server to 389 ldap server
by Serge.Sterck＠fmsb.be 08 Feb '10

08 Feb '10

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users February 2010