nscd sometimes gets "stuck"
by Sean Carolan
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.
13 years, 8 months
Documentation for pam pass
by Techie
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
13 years, 9 months
Issue with a Windows Replication Agreement
by Phil Daws
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
13 years, 9 months
inactivating some users after few days
by ankush grover
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
13 years, 9 months
Alias deref
by Emmanuel BILLOT
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
==========================================
13 years, 9 months
Error "passwords with storage scheme are not allowed" during modify and add operation
by Fabio Isgrò
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ò
13 years, 9 months
Fwd: Error in add and modifying operation
by Fabio Isgrò
-------- 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ò
13 years, 9 months
importing large subtree crashes ns-slapd
by Christopher Wood
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.
13 years, 9 months