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
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.
3 years
Re: NetworkRadius CentOS pkg uses openldap-ltb which conflict with symas-openldap
by Dave Macias
On Thu, Mar 26, 2020 at 3:44 PM Quanah Gibson-Mount <quanah(a)symas.com>
wrote:
> Try it and see? I can't find any concrete documentation one way or the
> other, although it seems BuildRequires generally follows what Requires
> does. You may need to ask the people who maintain RPM.
>
> There are other issues in the spec file, however, like:
>
> --with-libfreeradius-ldap-include-dir=/usr/local/openldap/include \
> --with-libfreeradius-ldap-lib-dir=/usr/local/openldap/lib64 \
>
> are specific to LTB, might want to do something like they did around line
> 447 to only do this if the LTB openldap is in use.
>
Awesome!
Thank you very much for the input!
Will report how things go
-Dave
3 years, 2 months
AD proxy / CAPITAL letters in attributes
by Kevin Olbrich
Hi!
How can I disable the behavior of CAPITAL letters when OpenLDAP proxies an AD?
I know they should be case insensitive but I had to debug Rocketchat
for two hours to find, they use sAMAccountName (case sensitive) and
the app crashed because mine was named SAMACCOUNTNAME.
(I will open a bug there but I bet there is a lot of broken SW).
Kind regards
Kevin
3 years, 2 months
OpenLDAP-Proxy in front of AD - Non-DN bind
by Kevin Olbrich
Hi!
I'm new to OpenLDAP / Slapd and try to integrate it into our AD setup.
I followed this howto:
https://wiki.samba.org/index.php/OpenLDAP_as_proxy_to_AD
... and ended up with this config:
https://bitbucket.org/code-orange/django-cdstack-tpl-openldap-proxy/src/m...
Proxy mode works fine, I can bind with DN and password. So far so good.
TLS works perfectly.
On AD, I can bind using either domain\username or username(a)example.com.
Can I enable this again for my proxy? Atm this does not work: Invalid
DN-Syntax, invalid DN.
I try to provide a secure way to connect a remove machine to our AD to
read the contacts (a pbx).
Using the DN worked for some devices but some have issues because of
the length. If the DN is several OUs deep, the string is to long.
Thats why I would like to allow the sAMAccountName as username (or USN, etc.).
How can I solve this?
Do I need SASL for this?
Thank you very much!
Kind regards
Kevin
3 years, 2 months
issues while modifying the LDAP on Production
by Guni Hanchate
Hi,
we are getting some issues while modifying the LDAP on Production.
We restarted LDAP instance but same issue persist. I request you to suggest
on this . Let us know if you need any further information .
I can read an entry
From Cricetid via the VirtIP
[u5356968@cricetid ~]$ldapsearch -x -LLL -h 192.168.154.33
-b "o=mobistar.be" "uid=u5356968" cn
dn: uid=u5356968,ou=Techmahindra,ou=Partners,o=mobistar.be
cn: DEMOULIN Philippe
From Mousedeer to Mousedeer
u5356968@mousedeer # ldapsearch -x -LLL -p 3898 -h
192.168.154.97 -b "o=mobistar.be" "uid=u5356968" cn
dn: uid=u5356968,ou=Techmahindra,ou=Partners,o=mobistar.be
cn: DEMOULIN Philippe
But we cannot modify the entry.
u5356968@mousedeer # ldapmodify -p 3898 -h 192.168.154.97 -D"cn=directory
manager, o=mobistar.be" -w8ZQ7HUJS
dn: uid=013tes3477,ou=Dealer Users,ou=Partners,o=mobistar.be
changetype: add
add: mail
mail: 013test.test_osp_fr_hq(a)orange.be
adding new entry "uid=013tes3477,ou=Dealer Users,ou=Partners,o=mobistar.be"
ldap_add: Undefined attribute type (17)
additional info: add: attribute type undefined
This is the error I get:
Error while executing LDIF
- [LDAP: error code 17 - Undefined Attribute Type]
java.lang.Exception: [LDAP: error code 17 - Undefined Attribute Type]
at
org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.checkResponse(DirectoryApiConnectionWrapper.java:1280)
at
org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$600(DirectoryApiConnectionWrapper.java:109)
at
org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper$4.run(DirectoryApiConnectionWrapper.java:726)
at
org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.runAndMonitor(DirectoryApiConnectionWrapper.java:1175)
at
org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.checkConnectionAndRunAndMonitor(DirectoryApiConnectionWrapper.java:1109)
at
org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.modifyEntry(DirectoryApiConnectionWrapper.java:748)
at
org.apache.directory.studio.ldapbrowser.core.jobs.ImportLdifRunnable.importLdifRecord(ImportLdifRunnable.java:514)
at
org.apache.directory.studio.ldapbrowser.core.jobs.ImportLdifRunnable.importLdif(ImportLdifRunnable.java:272)
at
org.apache.directory.studio.ldapbrowser.core.jobs.ExecuteLdifRunnable.executeLdif(ExecuteLdifRunnable.java:157)
at
org.apache.directory.studio.ldapbrowser.core.jobs.ExecuteLdifRunnable.run(ExecuteLdifRunnable.java:123)
at
org.apache.directory.studio.ldapbrowser.core.jobs.UpdateEntryRunnable.run(UpdateEntryRunnable.java:59)
at
org.apache.directory.studio.connection.ui.RunnableContextRunner$1.run(RunnableContextRunner.java:112)
at
org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
[LDAP: error code 17 - Undefined Attribute Type]
3 years, 2 months
logging through systemd-journald is bottleneck
by Markus.Storm＠t-systems.com
Dear all,
we're currently testing performance of OpenLDAP on Oracle/RedHat Linux and quite unexpected actually hit systemd-journald to be a bottleneck. While OpenLDAP happily makes use of all available CPUs, that one is single threaded, braking everything. The only way around I have found is to set olcLoglevel to 0, speeding up my test run by a factor of 6(!).
That now of course is not an option to use in production.
I'd happily directly write to a file as I did in the old days but I cannot get olcLogfile to work. And even if I was able to get there, how do I stop OpenLDAP from logging to syslogd (which is inevitably forwarding everything to system-journald ....) ?
Can anyone give advice how to handle this ? Any hint appreciated (short of "get a decent OS" - that is not an option).
Thanks,
Markus
3 years, 2 months
Antw: [EXT] Re: logging through systemd-journald is bottleneck
by Ulrich Windl
>>> Dieter Klünter <dieter(a)dkluenter.de> schrieb am 18.03.2020 um 19:57 in
Nachricht
<30206_1584557842_5E726F12_30206_1570_1_20200318195706.1d992aa0(a)pink.fritz.box>:
> Am Wed, 18 Mar 2020 17:16:53 +0000
> schrieb <Markus.Storm(a)t-systems.com>:
>
>> Dear all,
>>
>> we're currently testing performance of OpenLDAP on Oracle/RedHat
>> Linux and quite unexpected actually hit systemd-journald to be a
>> bottleneck. While OpenLDAP happily makes use of all available CPUs,
>> that one is single threaded, braking everything. The only way around
>> I have found is to set olcLoglevel to 0, speeding up my test run by a
>> factor of 6(!). That now of course is not an option to use in
>> production. I'd happily directly write to a file as I did in the old
>> days but I cannot get olcLogfile to work. And even if I was able to
>> get there, how do I stop OpenLDAP from logging to syslogd (which is
>> inevitably forwarding everything to system-journald ....) ? Can
>> anyone give advice how to handle this ? Any hint appreciated (short
>> of "get a decent OS" - that is not an option).
>
> I support Qanah's advice!
> Beside this, consider a logging strategy based on required information
> and neglected information, as well as min. and max. server load.
>
> Based on my experience I would disable logging as default, but enable
> logging for a short given time, just a modify operation on atribute
> olcLogLevel.
> With regard to journald I advice to define filters, see man
> journalctl(1).
> If syslog is a requirement, change to rsyslog. Don't make use of
> logstash!
Can't openLDAP simply log to a different port than the default syslog port?
If so, just set up some alternate local syslog server.
Or, in case an external syslog server is supported, just use one that isn't
using systemd-journald.
Sorry, I neved had the need to use a different syslog mechanism...
>
> -Dieter
>
> --
> Dieter Klünter | Systemberatung
> http://sys4.de
> GPG Key ID: E9ED159B
> 53°37'09,95"N
> 10°08'02,42"E
3 years, 2 months
write ACL
by Thomas Elsäßer
Hi ACL Gurus
i would like following ACL , but i'm to stupid.
cn=app1,ou=application,dc=company,dc=de -> groupOfNames
Our Customer Admins are here
cn=GroupLdapAdmin,o=customer1,ou=customer,dc=company,dc=de -> groupOfNames
cn=GroupLdapAdmin,o=customer2,ou=customer,dc=company,dc=de ->
groupOfNames member is the admin of this tree example
member=cn=customer2.admin,ou=user,o=customer2,ou=customer,dc=company,dc=de
I have 600 Customerx
How can i write one ACL for all customer to access to
cn=app1,ou=application,dc=company,dc=de to write access for
groupLDAPAdmin for every company?
This work for one customer
access to dn.regex="cn=([^,]),ou=application,dc=company,dc=de" by by
set.expand="(user) &
([cn=GroupLdapAdmin,o=customer1,ou=customer,dc=company,dc=de])/member" write
How can write this for all without write 600 ACL?
Thanx and stays healthy
Thomas
3 years, 2 months
