389-users March 2010

389-users@lists.fedoraproject.org

53 participants
57 discussions

nscd sometimes gets "stuck"
by Sean Carolan 22 Mar '10

22 Mar '10

I'm testing the 389 directory server in our lab environment before moving it to production and have noticed that occasionally it won't let me log in. I have to restart the nscd service before it will authenticate my user. Here's the error in /var/log/secure: Mar 22 09:59:31 watcher sshd[18109]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.2.3.100 user=scarolan Mar 22 09:59:31 watcher sshd[18109]: pam_ldap: error trying to bind as user "uid=scarolan,ou=People, dc=companyname, dc=com" (Invalid credentials) Has anyone else experienced something like this? Any idea what causes it? I want to make sure our LDAP authentication is rock-solid reliable before moving it into the production environment.

3 3

Documentation for pam pass
by Techie 18 Mar '10

18 Mar '10

Hello, Does anyone know if there is more pam pass through documentation out there. I see the FDS how to but it does not explain how to connect to the other server. I am trying to use my 389 server for authorization but OpenLDAP for authentication. Thank you

1 0

Issue with a Windows Replication Agreement
by Phil Daws 18 Mar '10

18 Mar '10

Hello all ... I am attempting to create a windows sync agreement but receiving the following error message "Replica has no update vector. It has never been initialized" We have recently rebuilt the windows AD server and was setting up the replication again once we had deleted the old agreement. What is strange is that the error above appeared before I have even created the new agreement and as soon as I created the new agreement the slapd error log shows: [18/Mar/2010:11:31:29 -0400] - add value "^V" to attribute type "ARecord" in entry "DC=@,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value [18/Mar/2010:11:31:29 -0400] - add value "null or non-ASCII" to attribute type "dnsproperty" in entry "DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: dupli Any ideas please ? it is though something from the old agreement still exists in the DIT -- Thanks, Phil

1 0

inactivating some users after few days
by ankush grover 18 Mar '10

18 Mar '10

Hi Friends, I have installed and configured 1.26a2 on Centos 5 and now want to implement a new role/policy for inactivating of some user accounts after few days like 30/45 days. The passwords of these users should remain same rather their account get should get locked or disabled something like 'usermode -e 2010-05-20 username' on a linux machine. Is there any way I can do the same on 389? Regards Ankush

1 0

Reindexing the database
by Diretorio Livre 17 Mar '10

17 Mar '10

2 1

Alias deref
by Emmanuel BILLOT 17 Mar '10

17 Mar '10

Hi, We want to use alias entries like that : # gri, ird.fr dn: uid=gri,dc=titi,dc=fr aliasedObjectName: uid=pfff,ou=people,dc=aga,dc=titi,dc=fr objectClass: top objectClass: alias objectClass: extensibleobject uid: gri - uid=pfff,ou=people,dc=aga,dc=titi,dc=fr is valid. - ldapsearch - a always -x -b "dc=titi,dc=fr" "uid=gri" gives exactly the entrie result, without dereferencing. - ldapsearch - a never -x -b "dc=titi,dc=fr" "uid=gri" gives exactly the entrie result, without dereferencing. There are some things we don't understand in alias. How does it work ? Same things on groups : # admin, groups, titi.net dn: cn=admin,ou=groups,dc=titi,dc=net memberURL: ldap:///dc=titi,dc=net??sub?(uid=x*) objectClass: top objectClass: groupofuniquenames objectClass: groupofurls cn: admin we can't see members when listing -- ========================================== Emmanuel BILLOT IRD - Orléans Délégation aux Systèmes d'Information (DSI) tél : 02 38 49 95 88 ==========================================

1 0

Error "passwords with storage scheme are not allowed" during modify and add operation
by Fabio Isgrò 17 Mar '10

17 Mar '10

Hi to all, this is the third time I send this mail but for somewhat reason it doesn't accepted. Have a great day. Fabio Hi to all, I'm using the lastest stable version of 389-ds and I have a strange issue when cut and paste an user from a branch to another or import an user that has SSHA as password scheme. This is a specimen of user extracted with db2ldif > # entry-id: 41964 > dn: uid=TestUser,ou=Milano,ou=PuntiPeriferici,ou=Persone,o=Domain > mail: testUser(a)domain.it > uid: testUser > givenName: testUser > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: inetorgperson > sn: testUser > cn: testUser > userPassword: {SSHA}Qm33jLgIeXUNOOdESn9g+fMeg59ecxRQnRPKMA== > creatorsName: > uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot > modifiersName: > uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot > createTimestamp: 20100205124926Z > modifyTimestamp: 20100205124926Z > nsUniqueId: c2d9a301-1dd111b2-80d0d492-e75cfaf > When I'm trying to import this ldif via mozldap ldapmodify or console I get this error uid=TestUser,ou=Milano,ou=PuntiPeriferici,ou=Persone,o=Domain: netscape.ldap.LDAPException: error result (19); invalid password syntax - passwords with storage scheme are not allowed intestead with OpenLdap ldapmodify it works Perfectly. Some ideas ? Thanks in Advance Fabio Isgrò

1 0

Reindexing the database
by Diretorio Livre 17 Mar '10

17 Mar '10

2 1

Fwd: Error in add and modifying operation
by Fabio Isgrò 16 Mar '10

16 Mar '10

-------- Original Message -------- Subject: Error in add and modifying operation Date: Mon, 15 Mar 2010 18:01:16 +0100 From: Fabio Isgrò <fabio.isgro(a)messinalug.org> Organization: Me|Lug To: General discussion list for the 389 Directory server project. <389-users(a)lists.fedoraproject.org> Hi to all, I'm using the lastest stable version of 389-ds and I have a strange issue when cut and paste an user from a branch to another or import an user that has SSHA as password scheme. This is a specimen of user extracted with db2ldif > # entry-id: 41964 > dn: uid=TestUser,ou=Milano,ou=PuntiPeriferici,ou=Persone,o=Domain > mail: testUser(a)domain.it > uid: testUser > givenName: testUser > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: inetorgperson > sn: testUser > cn: testUser > userPassword: {SSHA}Qm33jLgIeXUNOOdESn9g+fMeg59ecxRQnRPKMA== > creatorsName: > uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot > modifiersName: > uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot > createTimestamp: 20100205124926Z > modifyTimestamp: 20100205124926Z > nsUniqueId: c2d9a301-1dd111b2-80d0d492-e75cfaf > When I'm trying to import this ldif via mozldap ldapmodify or console I get this error uid=TestUser,ou=Milano,ou=PuntiPeriferici,ou=Persone,o=Domain: netscape.ldap.LDAPException: error result (19); invalid password syntax - passwords with storage scheme are not allowed intestead with OpenLdap ldapmodify it works Perfectly. Some ideas ? Thanks in Advance Fabio Isgrò

1 0

importing large subtree crashes ns-slapd
by Christopher Wood 15 Mar '10

15 Mar '10

I'm just getting started with 389 Directory Server (at work), and I've run into an issue that I'm not certain how to troubleshoot. I would greatly appreciate any assistance or tips you could offer, especially on where to look to see what's failing. Also, I apologize in advance for changing strings related to my employer's directory names and such, as I'm not comfortable with leaking that level information to a public list. Overview: Initializing a large subtree from NDS 6.2 crashes ns-slapd, but other subtrees are fine. Top-Level Questions: 1) How do I stop ns-slapd from crashing? 2) How do I figure out what precisely is causing the crash? (With various levels of debug logging I get the same log entry.) 3) Is it possible to simply import my initialization ldif without duplication checks? Background: At work we have NDS 6.2 (single master on a physical server, virtual machine slaves), and would like to move our directories intact to a 389 2.6 installation via replication. I already have replicated several of our NDS 6.2 subtrees to 389 2.6 with no difficulties. I compiled our 389 installation from the source packages downloaded from http://directory.fedoraproject.org/wiki/Source. The underlying platform is: $ uname -a Linux cwlab-02.mycompany.com 2.6.18-164.el5 #1 SMP Thu Sep 3 03:33:56 EDT 2009 i686 i686 i386 GNU/Linux $ cat /etc/redhat-release CentOS release 5.4 (Final) $ free total used free shared buffers cached Mem: 3894000 1336012 2557988 0 144944 1004716 -/+ buffers/cache: 186352 3707648 Swap: 2031608 0 2031608 Procedure To Crash 389's ns-slapd: a) In the NDS 6.2 admin console, create a new replication agreement for the "o=This Big Net" subtree, and choose to "Create consumer initialization file". b) Copy the file to the 389 server. c) In the 389 2.6 admin console for the Directory Server, in the Configuration tab (Data -> o=This Big Net -> dbRoot), right-click and choose "Initialize Database". Use the ldif file copied over. The ns-slapd process crashes, and I always get this in /opt/dirsrv/var/log/dirsrv/slapd-cwlab-02/errors as the last two lines: [03/Mar/2010:12:50:04 -0500] - import ldapAuthRoot: Processing file "/home/cwood/tbn.ldif" [03/Mar/2010:12:50:04 -0500] - => str2entry_dupcheck Other Details: I found two bugs with the str2entry_dupcheck string in it, but they don't seem pertinent: https://bugzilla.redhat.com/show_bug.cgi?id=548115 https://bugzilla.redhat.com/show_bug.cgi?id=243488 This says that str2entry_dupcheck could be about two things: http://docs.sun.com/source/816-6699-10/ax_errcd.html "While attempting to convert a string entry to an LDAP entry, the server found that the entry has no DN." "The server failed to add a value to the value tree." (But this is an exported database from NDS 6.2, and I'm fairly sure, without reading them all, that every entry will have a DN.) If 389 is trying to check for duplicate entries, perhaps there are simply too many DNs? $ grep '^dn:' tbn.ldif | wc -l 636985 $ ls -lh acc.ldif -rw-r--r-- 1 cwood cwood 755M Mar 3 11:24 tbn.ldif Per the instructions here: http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting I set my debug logging first to 24579: 1 Trace function calls 2 Debug packet handling 8192 Replication debugging 16384 Critical messages Then for the next try at reading logs I set it to 90115, the above plus: 65536 Plug-in debugging However, every time the log ended with the same set of lines noted above.

2 9

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users March 2010