When a use hits the PasswordWarnTime and flips the PasswordExpWarned, the
date of PasswordExpirationTime advances to 10 days from now. The warn time
for the subtree is 7. Can any explain what is doing this, so I can turn it
Here¹s how my PAM PTA looks like. But id on;t think it is of much use.
dn: cn=PAM Pass Through Auth,cn=plugins,cn=config
I don¹t think the PTA will work against some other attribute which has same
value as uid¹. You may have to hack the filters under the hood to be able
to achieve that.
My first guess:
If you use PAM-PTA, you still need some PAM module to specify the stack to
be used for PTA. So you need ldapserver01¹ file enabled and there you
define the translation of uid attribute to new attribute. I don¹t know if
this is do-able.
Can you post some logs, which will tell where the block is. How are you
specifying the master ldap server(server to authenticate)?
Hey thanks man.
I have PAM PTA with krb working fine as well..
However..I am trying to pass through to another LDAP server, how can i
go about doing that? The base of the tree on the other LDAP server is
different i want to use it to authenticate the accounts. The other
tree has the equivalent of the uid attribute in a different attribute.
I think my service file (ldapserver) is off. Anyone have PAM PTA to
another LDAP server working? An example perhaps?
I am getting operations errors trying to use PAM PTA. I know the
passwords are correct so I am doing something incorrectly.
pam_passthru-plugin - => pam_passthru_bindpreop
pam_passthru-plugin - pam msg  = 1 Password:
pam_passthru-plugin - Error from PAM during pam_authenticate (6:
pam_passthru-plugin - Unknown PAM error [Permission denied] for user
id [test_user], bind DN [uid=test_user,dc=example,dc=com]
pam_passthru-plugin - <= handled (error 1 - Operations error)
Hello, all. We are experiencing a weird problem and have not been able
to fix it. We have just renamed the top level of our tree from
dc=old,dc=biz to dc=new,dc=com. All went very well (well, very well
until we also changed the certificates and keys to be from the new
Certificate Authority - but we have that sorted now, too) except one
Our Zimbra (6.0.5) mail server authenticates users against our CentOS
8.1 Directory Server. It is working but, every time a user tries to
authenticate, we generate an error:
slapi_search_internal ("CN=zimbra.new.com, OU=MailServers, DC=new, DC=com", subtree, objectclass=*) err 32
and in the access log we see:
conn=174 SSL 128-bit RC4; client CN=zimbra.new.com,OU=MailServers,DC=new,DC=com; issuer CN=newca.new.com,OU=PKI,DC=new,DC=com
conn=173 SSL failed to map client certificate to LDAP DN (No such object)
We then see the directory search user (we do not allow anonymous access)
correctly bind and authenticate.
It is as if the directory server is accidentally trying to do cert
mapping and authenticate the mail server whenever it tries to establish
an ldaps connection. As far as I understand, one needs to tell
Directory Server to do this by adding a usercertificate attribute to the
user we want to authenticate via X.509 cert. I've searched the entire
database dump and nothing has that attribute. certmap.conf has been
unchanged and is all commented out except for:
certmap default default
What is causing this and how do I fix it?
Our migration procedure was to stop dirsrv, dump the userRoot and
NetscapeRoot databases, make all the substitutions via sed in dse.ldif
(and .bak and .startOK), make all the substitutions via sed in the
database dumps, and then import the revised ldif files. Thanks - John
I have noticed on my Fedora consumers there appear to be quite a few
tombstones going back months even thought the Purge delay is set to a week:
ldapsearch -x -b "cn=mapping tree,cn=config" -D "cn=Directory Manager"
-W cn=replica nsds5ReplicaPurgeDelay
# replica, o=blah.com, mapping tree, config
dn: cn=replica,cn="o=blah.com",cn=mapping tree, cn=config
--- example tombstone ---
# ad82a101-1dd111b2-80a3f995-55bd0000, bob(a)zzz.com, Blah, blah.com
There seems to be hundreds of these dating back 6 months to when the
server was built. Why are these old entries not being purged?
Hello, all. We've recently undergone a corporate name and domain
change, let's say from oldname.biz to newname.com. Consequently, we
need to rename the top level of our LDAP structure. We installed CentOS
Directory Server 8.1 into dc=oldname,dc=biz and now need that entire
structure to have dc=newname,dc=com at the top. Everything else stays
I realize I'll need to edit all my ACIs and repoint all my LDAP clients,
but is there an easy way to rename the tree? I'd hate to try to move all
the elements (especially since I believe we can only move leaves) and
worse yet have to recreate the entire tree :-((((
I assume it is not as simple as going to the top level object in the
directory, going to advanced properties and changing the entrydn.
Thanks - John
I have been given a bunch of old Netscape 6.2 servers that need
replacing with 389 Directory server, is it possible to have a Netscape
6.2 master and a 389 Directory server replicating between each other?
The current setup consists of 2 Netscape Multimasters and 7 slaves, I
think the easiest solution would be to build 2 389 Masters with 389
slaves and have at least one of each Masters replicating between each
other. Then to move the applications to the new platform the clients
just need to change the IP they are talking to, then we always have the
option of moving back if there are any problems.
Does this sound like a sensible way to do it? The Netscape boxes are
actually critical production boxes so we can afford very little downtime
if any, and if we have the 2 setups replicating to each other the
rollback plan is easy - otherwise we will need to somehow log all
changes and manually apply those either way to keep everything in sync
when we cutover and rollback.
I'm rather new to LDAP so its a steep learning curve!
Thanks in advance for any pointers.
I read, Howard Chu 2003, that a SLAPI plug-in was available for syncing LDAP passwords to the equivalent Samba NT/LM. Would anybody know whether this is still available ? or is there another solution now ?