Problem with "force user to password reset at first login
by Rajagopal Rc
Hi,
I am trying to force users to change their password at first login or
after
password reset by administrator.
Tried following:
1)Password policy 'pwdMustChange TRUE' doesn't seems to be working as non
of the
users get prompt to change their password at first login.
2) used the 'pwdReset TRUE' attribute in users attributes, and it won't
prompt
to change the password and didn't allow to login
i observe below messages in log
"slapd[12684]: connection restricted to password changing only
slapd[12684]: send_ldap_result: err=50 matched="" text="Operations are
restricted to bind/unbind/abandon/StartTLS/modify password"
slapd[12684]: conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0
text=Operations are restricted to bind/unbind/abandon/StartTLS/modify
password"
Please help me configure the option to force all users to change their
password
at first login or after pwd reset by administrator.
Thanks & Regards
Raj
Tata Consultancy Services
Mailto: rajagopal.rc(a)tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
1 month
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
3 years, 4 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, 5 months
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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 months
