Q: UNKNOWN attributeDescription "AUDITCONTEXT" inserted.
by Ulrich Windl
Hi!
After systemd tearing down one of our LDAP servers I noticed the following message when the server was restarted:
slapd[10525]: UNKNOWN attributeDescription "AUDITCONTEXT" inserted.
The next line logged was:
slapd[10525]: olcServerID: value #1: SID=0x002 (listener=ldap://...:389)
(the server is that of SLES12 SP4, 2.4.41 from opensuse-buildservice)
The server is one of three MM servers that all have the same configuration and the same version.
The schema knows in olcAttributeTypes (olcSchemaConfig):
( 1.3.6.1.4.1.4203.666.11.5.1.30 NAME 'auditContext' DESC 'DN of auditContainer' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
What I'l like to know: Is there any thing I could fix in the configuration to make the message go away, or is it some software issue in slapd?
Regards,
Ulrich
2 years, 10 months
Remove/change replication partner
by Jean-Luc Chandezon
Hello,
I'm trying to remove replication partner (olcSyncrepl overlay).
Here are results for partner parameter(config):
# ldapsearch -LLLY external -H ldapi:/// -b "olcDatabase={0}config,cn=config" olcSyncRepl
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: olcDatabase={0}config,cn=config
olcSyncrepl: {0}rid=01 provider=ldap://bea-olp-001.lan-explore.fr binddn="
cn=replication,dc= lan-explore,dc=fr" bindmethod=simple credentials=i2Df
0rXiQokb8HtYZemJ searchbase="cn=config" type=refreshAndPersist retry="5 5 300
5" timeout=1
olcSyncrepl: {1}rid=02 provider=ldap://cdb-olp-001. lan-explore.fr binddn="
cn=replication,dc= lan-explore,dc=fr" bindmethod=simple credentials=i2Df
0rXiQokb8HtYZemJ searchbase="cn=config" type=refreshAndPersist retry="5 5 300
5" timeout=1
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
dn: olcOverlay={1}syncprov,olcDatabase={0}config,cn=config
dn: olcOverlay={2}syncprov,olcDatabase={0}config,cn=config
I tested this query:
dn: olcDatabase={0}config,cn=config
changetype: modify
delete: olcSyncrepl
The result is:
ldapmodify -Y EXTERNAL -H ldapi:/// -f removeConfigPartner.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={0}config,cn=config"
ldap_modify: Server is unwilling to perform (53)
additional info: shadow context; no update referral
Please what I missed?
Thanks,
Jean-Luc
2 years, 11 months
pwdChangedTime not defined when creating new entry
by Manuela Mandache
Hello all,
We have a directory running on OpenLDAP 2.4.44 with the ppolicy overlay on the main database. When a new entry with a userPassword defined is created, pwdChangedTime is not defined, so this initial userPassword never expires.
The directory has been migrated from its OpenLDAP 2.3.34 instance (yes, we missed some steps...), and there the pwdChangedTime is set, and naturally equal to createTimestamp.
The overlay is configured as follows:
dn: olcOverlay={2}ppolicy,olcDatabase={2}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: {2}ppolicy
olcPPolicyDefault: ou=ppolicy,dc=example,dc=com
olcPPolicyHashCleartext: TRUE
olcPPolicyUseLockout: TRUE
Is there a parameter I missed which would switch on setting pwdChangedTime at entry creation? Do I have to provide some other configuration elements?
Or is it unreasonable to expect this initialisation of the attribute this way, and only a password change can set it? I think the setting at creation is rather handy... Using pwdMustChange would be difficult, we have a lot of client apps which would be forced to check and probably adapt their authentication procedures.
Thank you and regards,
Manuela
Sent with [ProtonMail](https://protonmail.com) Secure Email.
2 years, 12 months
userPassword is not replicated
by razvanpopescu＠hotmail.com
Hi,
I have set up a replication master/slave between 2 openldap 2.4.44 on rhel 7.x.
On the slave server, the userPassword attribute is not replicated by syncrepl, all other attributes are replicated OK
The replication has been set up as follow:
On master server (provider), I have set up :
# replication
moduleload syncprov
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
On slave server (consumer), I've set up in the /etc/openldap/slapd.conf:
# replication
syncrepl rid=100
provider=ldaps://fr-te-ldap-x1.intra.commercial-union.fr
type=refreshAndPersist
searchbase="dc=aviva,dc=fr"
scope=sub
schemachecking=on
bindmethod=simple
filter="(objectClass=*)"
binddn="cn=admin,dc=aviva,dc=fr"
credentials=redhat
retry="15 +"
index entryUUID,entryCSN eq
sizelimit 100000
On both server ( master, slave) , the ACL has been set up as follow :
access to attrs=userPassword
by self write
by anonymous auth
by * read
access to *
by self read
by users read
by anonymous read
Please help me !
What is wrong in this configuration and why the userPassword attribute is not replicated on slave side ?
Please advice me,
Thank,
Razvan
2 years, 12 months
what does "error 131 (State not recoverable)" indicate?
by James Anderson
good evening;
i am looking for an explanation for a situation which we encountered with an lmdb database and library version is 0.9.17-3.
the database's condition was such that all attempts to open it for reading failed.
in at least some cases the error appears to have occurred during the operation which looked for stale leaders.
a problem was also evident when attempting to copy the database:
@nl12:~# mdb_copy /srv/dydra/catalog/repositories/d2141030-9495-c040-b1a7-9e19edbeb491/ /srv/dydra/backups/public-data__rev
mdb_copy: copying failed, error 131 (State not recoverable)
it was first evident in running processes which had already had the database open, but of which new threads were reopening the database environment.
the only thing remarkable about the circumstances involved might have been that while several dozen threads were preparing reading simultaneously and in the processes of opening the environment to read, a monitoring thread took a snapshot of the threads, which entailed interrupting each to generate its stack trace.
once we identified and terminated all processes which had the environment open, successive open attempts succeeded.
when we examined the content, however, although the space was still occupied on disk and the transaction id reflected the prior content, the indices were empty.
- what condition does that message intend to describe?
- what can cause that condition?
- would there have been some way to have recovered the old state - despite that message?
3 years
Antw: [EXT] LMDB does not recover on restart.
by Ulrich Windl
>>> Vipul Jain <vipul5798(a)gmail.com> schrieb am 28.05.2020 um 15:51 in Nachricht
<15586_1590677913_5ECFD199_15586_106_1_CALsDq61nAgNh1Z3eUK=CNk_b7uWXgQ6aZYOzQvsn
G-DPXQd2g(a)mail.gmail.com>:
> In standalone application, I have insert 10 key,value using LMDB.
> but if application crash and restart, and then I am trying to access the
> same LMDB DB file, I am not able to see any data. it give error violating
> memory access.
Did the application commit the data before crash?
> Any solution for this?
>
> I am looking for LMDB persistence, On restart of application do not need to
> push key value again in LMDB.
>
> --
> with regards:-
> Vipul Jain
3 years
LMDB does not recover on restart.
by Vipul Jain
In standalone application, I have insert 10 key,value using LMDB.
but if application crash and restart, and then I am trying to access the
same LMDB DB file, I am not able to see any data. it give error violating
memory access.
Any solution for this?
I am looking for LMDB persistence, On restart of application do not need to
push key value again in LMDB.
--
with regards:-
Vipul Jain
3 years
ReviewBoard LDAP authentication issue
by Adam Weremczuk
Hi all,
I'm running old samba4 DC and trying to set up LDAP authentication for
https://www.reviewboard.org/docs/manual/3.0/admin/configuration/authentic...
These settings are almost working for me:
-> Authentication Method: LDAP
-> LDAP Server: ldap://192.168.x.x:389
-> Review Board LDAP Bind Account: cn=auth,cn=Users,dc=domain,dc=co,dc=uk
-> Review Board LDAP Bind Password: ********
-> LDAP Base DN: cn=Users,dc=domain,dc=co,dc=uk
-> Username Attribute: uid
-> Given Name Attribute: givenName
-> Surname Attribute: sn
-> Full Name Attribute: cn
-> E-Mail LDAP Attribute: mail
-> E-Mail Domain: (blank)
-> Custom LDAP User Search Filter: (blank)
I have a weird problem with about half of users being able to log in:
2020-05-26 11:32:07,623 - DEBUG - - root - Attempting to authenticate
user DN "CN=dummy1,CN=Users,DC=domain,DC=co,DC=uk" (username dummy1) in LDAP
and half unable:
2020-05-26 11:40:57,671 - ERROR - - root - Unexpected error
authenticating user "dummy2" in LDAP: 'NoneType' object has no attribute
'decode'
After ruling out the obvious such as AD groups membership and primary
groups I compared ldapsearch dumps:
ldapsearch -D 'admin(a)domain.co.uk' -b 'cn=Users,dc=domain,dc=co,dc=uk'
-H ldap://192.168.x.x -W sAMAccountName=dummy
I've noticed that all of those who cannot log in are missing msSFU30Name
and msDS-SupportedEncryptionTypes attributes.
I've added them to match settings for the successful users as below:
dummy2.ldif
dn: CN=dummy2,CN=Users,DC=domain,DC=co,DC=uk
changetype: modify
add: msSFU30Name
msSFU30Name: dummy2
add: msDS-SupportedEncryptionTypes
msDS-SupportedEncryptionTypes: 0
ldbmodify -H /var/lib/samba/private/sam.ldb dummy2.ldif -U dummy2
Modified 1 records successfully
Unfortunately it didn't help :(
Any ideas why?
Thanks,
Adam
3 years
replication issue. Incorrect ACL?
by Gao
Hello,
We have two Openldap server in master-slave replication. I just found
that a replication issue on the slave and I think it is ACL related.
Few weeks ago I added ACL on the master (ldap-01) to allow user change
their own password:
dn: olcDatabase={2}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {2}hdb
olcDbDirectory: /var/lib/ldap
olcDbIndex: objectClass eq,pres
olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: loginShell eq
olcDbIndex: uid eq,pres,sub
olcDbIndex: memberUid eq,pres,sub
olcDbIndex: uniqueMember eq,pres
olcDbIndex: sambaSID eq
olcDbIndex: sambaPrimaryGroupSID eq
olcDbIndex: sambaGroupType eq
olcDbIndex: sambaSIDList eq
olcDbIndex: sambaDomainName eq
olcDbIndex: default sub
structuralObjectClass: olcHdbConfig
entryUUID: 3b7e5722-d26f-1035-7735-91213c5bb357
creatorsName: cn=config
createTimestamp: 20160629180122Z
olcSuffix: dc=van,dc=company,dc=com
olcRootDN: cn=Manager,dc=van,dc=company,dc=com
olcRootPW:: e1NTSEF9cEpWbEIzOEh4UXJpcjnvSUl2enZzWTF1akt4Nnd6OTk=
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by
dn.ba
se="cn=Manager,dc=van,dc=company,dc=com" write by * none
olcAccess: {1}to * by self write by dn="cn=Manager,dc=van,dc=company,dc=
com" write by * read
entryCSN: 20200504150528.806636Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20200504150528Z
Now I found on the slave(ldap-03) all userPassword attributes is
disappeared. So I think the ACL may blocked the replication. I think I
need add the replication user (rpuser) to the ACL on the master and
allow the rpuser read(or RW?) access.
Could someone check my ACL and see if my guess is correct? If so then
how do I add (or append?) the ACL to allow replication of the
userPassword?
Thank you in advance.
Gao
3 years
