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, 1 week
role based authorization -> dynacl module?
by Daniel Tröder
Hello everyone,
I am in the process of implementing a role concept via ACLs and hope for
a hint so that I don't invent the wheel a second time.
Specifically, it is about identity management for schools. A user
(object) can have several roles in multiple schools. Permissions on
other LDAP objects can thus differ depending on the role(s) the user and
the object have in the same school(s).
For example, a user could have been assigned the following roles that
are scattered over several schools:
→ "Teacher" in school 1
→ "School admin" in school 2
→ "Parent" in school 3
→ both "Teacher" and "Staff" in school 4
ACLs should now be defined accordingly, e.g.
→ the role "teacher" at school X can reset the password for the role
"student" at school X
→ the role "teacher" at school X *cannot* reset the password for the
role "student" of school Y
→ the role "school administrator" at school X can reset the password for
the roles "student" and "teacher" at school X
→ ...
So far I have not seen any way to map such a construct via groups or
sets without including a separate ACL for each group, which is a
performance issue.
Is there another way to map the role concept besides implementing an own
dynacl module?
Greetings,
Daniel
5 years, 2 months
Re: OpenLDAP instances crashes
by Saurabh Lahoti
Dear Leo,
We tried the steps mentioned below using the ReOpenLDAP package provided by
you.
But, we're start at the very first step while running bootstrap.sh &
encountered below errors:
root@pygarg # ./bootstrap.sh
./bootstrap.sh: line 39: git: command not found
Oops, cleanup failed ;(
Could you please guide us further into this..?
----
*Thanks & Kind Regards,*
Saurabh LAHOTI.
*Ideas enlighten Innovation**!!!*
Please consider the environment before printing this mail..!!
On Thu, 23 Aug 2018 at 23:17, Леонид Юрьев <leo(a)yuriev.ru> wrote:
> Hi, Saurabh.
>
> Your custom overlay "mobiuniquemember" now intergated into ReOpenLDAP
> (mobiuniquemember branch).
> Please check it:
>
> git clone https://github.com/leo-yuriev/ReOpenLDAP.git -b mobiuniquemember
> cd ReOpenLDAP
> ./bootstrap.sh
> ./configure --enable-contrib [other relevan options]
> make install
>
> Regards,
> Leonid.
>
>
> ср, 22 авг. 2018 г. в 18:04, Леонид Юрьев <leo(a)yuriev.ru>:
>
>> You could submit source code of your custom overlay to
>> https://github.com/leo-yuriev/ReOpenLDAP, i.e. pull-request into the
>> 'devel' branch.
>>
>> Then I will try fix it and merge-in, in success case you will be able to
>> build and use it with ReOpenLDAP.
>>
>>
>> Regards,
>> Leonid.
>>
>> ср, 22 авг. 2018 г., 17:37 Saurabh Lahoti <saurabh.astronomy(a)gmail.com>:
>>
>>> Dear,
>>>
>>> What is you're recommendation to fix this problem on our side..? It's
>>> been haunting our operational activities on daily basis.. 😓
>>> ----
>>>
>>> *Thanks & Kind Regards,*
>>> Saurabh LAHOTI.
>>> *Mob: +32.499.82.37.88*
>>> *Ideas enlighten Innovation**!!!*
>>> Please consider the environment before printing this mail..!!
>>>
>>>
>>>
>>>
>>>
>>> On Fri, 17 Aug 2018 at 16:43, Brian Reichert <reichert(a)numachi.com>
>>> wrote:
>>>
>>>> On Thu, Aug 16, 2018 at 02:00:20PM +0200, Saurabh Lahoti wrote:
>>>> > Dear,
>>>> >
>>>> > Today, received below error in /var/log/messages with OpenLDAP
>>>> instance
>>>> > crashing.
>>>>
>>>> That looks like either:
>>>>
>>>> - You have a bad SIM (very unlikely)
>>>> - You have a corrupted uniquemember.so.0.0.0 shared library.
>>>> - You may have conflated OpenLDAP packages installed that have a
>>>> critical
>>>> incompatibility amidst the installed binaries/libraries.
>>>>
>>>> It did write a core file; there are many tutorials about exploring
>>>> a core file to help understand why the segfault occurred.
>>>>
>>>> >
>>>> > Aug 16 13:21:07 muledeer kernel: slapd[29253]: segfault at 0 ip
>>>> > 00007fbeddf3af09 sp 00007fb72effc480 error 4 in
>>>> > uniquemember.so.0.0.0[7fbeddf3a000+2000]
>>>> > Aug 16 13:21:08 muledeer abrt[24629]: Saved core dump of pid 16470
>>>> > (/usr/app/ldap/openldap2.4.46/libexec/slapd) to
>>>> > /var/spool/abrt/ccpp-2018-08-16-13:21:07-16470 (472973312 bytes)
>>>> > Aug 16 13:21:08 muledeer abrtd: Directory
>>>> 'ccpp-2018-08-16-13:21:07-16470'
>>>> > creation detected
>>>> > Aug 16 13:21:08 muledeer abrtd: Executable
>>>> > '/usr/app/ldap/openldap2.4.46/libexec/slapd' doesn't belong to any
>>>> package
>>>> > and ProcessUnpackaged is set to 'no'
>>>> > Aug 16 13:21:08 muledeer abrtd: 'post-create' on
>>>> > '/var/spool/abrt/ccpp-2018-08-16-13:21:07-16470' exited with 1
>>>> > Aug 16 13:21:08 muledeer abrtd: Deleting problem directory
>>>> > '/var/spool/abrt/ccpp-2018-08-16-13:21:07-16470'
>>>> >
>>>> >
>>>> > Could you please guide us in finding probable root of this error..?
>>>> > ----
>>>> >
>>>> > *Thanks & Kind Regards,*
>>>> > Saurabh LAHOTI.
>>>> > *Ideas enlighten Innovation**!!!*
>>>> > Please consider the environment before printing this mail..!!
>>>>
>>>> --
>>>> Brian Reichert <reichert(a)numachi.com>
>>>> BSD admin/developer at large
>>>>
>>>
5 years, 2 months
duplicated naming context when using syncrepl proxy
by Jochen Keutel
Hallo,
I'm using OpenLDAP on Debian 9 (2.4.44) and started to configure
replication: szenario syncrepl proxy (push based replication, see 18.3.5
in OpenLDAP Admin Guide - "primary directory also contains back-ldap
databases"). Configuring the LDAP backend leads unfortunately to a root
DSE showing the same name context twice:
namingContexts: dc=keutel,dc=de
namingContexts: dc=keutel,dc=de
Is this a known problem? Esp. this stops PHPLDAPAdmin from working: It
prints a lot of PHP arrays in this case.
I've set "hidden on" for this backend but the problem remains.
My configuration:
1. slapd.conf on server1 (master):
database ldap
hidden on
suffix "dc=keutel,dc=de"
rootdn "cn=admin,dc=keutel,dc=de"
uri ldaps://server2/
lastmod on
restrict all
acl-bind bindmethod=simple
binddn="cn=replication,dc=keutel,dc=de"
credentials=secret
syncrepl rid=001
provider=ldaps://server1/
binddn="cn=replication,dc=keutel,dc=de"
bindmethod=simple
credentials=secret
searchbase="dc=keutel,dc=de"
type=refreshAndPersist
retry="5 5 300 5"
2. converting this to dynamic config using slaptest gives the following
entry:
dn: olcDatabase={2}ldap
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
olcDatabase: {2}ldap
olcHidden: TRUE
olcSuffix: dc=keutel,dc=de
...
3. starting slapd with this dynamic configuration
4. reading rootDSE: attribute namingContexts occurs twice with the same
value.
How can this be solved?
Regards
Jochen.
5 years, 3 months
Problem with ACLs
by Bill Bradford
Trying to give a single user "read only" access to everything in
the database including userPassword info.
Here's the LDIF file I'm using w/ldapmodify:
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange
by dn="cn=Manager,dc=domain,dc=com" write
by dn.exact="uid=romanager,ou=Users,dc=domain,dc=com" read
by anonymous auth
by self write
by * none
olcAccess: {1}to dn.base=""
by * read
olcAccess: {2}to *
by dn="cn=Manager,dc=domain,dc=com" write
by * read
However, authenticating as uid=romanager,ou=Users,dc=domain,dc=com
lets that user read his own password hash, but nobody else's. In
other words it's authenticating just like any other user, and it's
as if the
by dn.exact="uid=romanager,ou=Users,dc=domain,dc=com" read
line is being ignored. The change is being applied as I've looked
at the database files for the config. I've tried restarting slapd, etc.
Any suggestions?
@(#) $OpenLDAP: slapd 2.4.44 (Aug 4 2017 14:23:27) $
Bill
--
Bill Bradford
Houston, Texas USA
5 years, 3 months
empty reqmod attribute
by David Coutadeur
Hi,
I am experiencing a segfault on an OpenLDAP 2.4.44 instance.
The architecture is:
- 2 OpenLDAP
- multimaster mirrormode
- delta-syncrepl
The error seems to be in the syncrepl process, in a particular accesslog
entry.
When I give a look to the entry, I realize that some attributes in
reqmod are empty, which seems strange because the value can't be empty
in the directory. For example:
reqMod: inetUserStatus:=
Does anyone know if this behaviour is normal, and what is happening?
Thanks in advance.
David
5 years, 3 months
Unique overlay confusing
by Ervin Hegedüs
Hi there,
I've followed the docs (and some forums), and made these
modifications:
(OpenLDAP doc:
http://www.openldap.org/doc/admin24/overlays.html#Attribute%20Uniqueness)
dn: cn=module,cn=config
cn: module
objectClass: olcModuleList
olcModulePath: /usr/lib/ldap/
olcModuleLoad: unique.la
dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcUniqueConfig
olcOverlay: unique
olcUniqueAttribute: uid
olcUniqueAttribute: mail
olcUniqueAttribute: uidNumber
olcUniqueAttribute: sn
olcUniqueAttribute: cn
but I still can set the mail attribute as same e-mail address
for two different users.
I've tried this config too:
dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcUniqueConfig
olcOverlay: unique
olcUniqueUri: ldap:///?uid?sub?
olcUniqueUri: ldap:///?mail?sub?
olcUniqueUri: ldap:///?uidNumber?sub?
olcUniqueUri: ldap:///?sn?sub?
olcUniqueUri: ldap:///?cn?sub?
What em'I missing?
Thanks,
a.
5 years, 3 months
Call fo Papers - Paris Open Source Summit
by Clément OUDOT
Hello,
There is an important event about free software and open source in
Paris in december, with topics about identity management. The CFP is
here: http://cfp.opensourcesummit.paris/
It should close friday but I think the deadline will be reported.
Feel free to propose technical talks or customer success stories (for
example migration from proprietary softwares to free softwares).
Hope to see you soon,
Clément.
5 years, 3 months
Recommended way to transfer data from one cluster to the other?
by Karsten Heymann
Hi,
We're replacing our aging LDAP Cluster (Debian 7, slapd 2.4.40, 2
masters with syncrepl and mirror mode, 2 slaves) with a new cluster of
the same layout (2.4.44, probably 2.4.46, on Debian 9). I now wonder
what the best way is to transfer the data from the old to the new
cluster. As far as I can see, we have three options to transfer the
data:
1) ldapsearch + ldapadd
2) slapcat + slapadd
3) Configure a temporary syncrepl rule on the new masters to fetch the
data from the old ones.
Which one is the preferred one? I would assume slapcat and slapadd,
but I must admit I have not fully understood the purpose of the -S and
-w switch. Should we somehow filter the *CSN-fields from the exported
ldif as I assume they make no sense for the new cluster or are they
automatically fixed when using slapadd with said options?
I'm sorry if this topic has been discussed here before but my
(probably lacking) google skills did not return anything obvious.
Best regards
Karsten
5 years, 3 months
Re: Recommended way to transfer data from one cluster to the other?
by Quanah Gibson-Mount
--On Wednesday, August 29, 2018 12:50 PM +0200 Karsten Heymann
<karsten.heymann(a)gmail.com> wrote:
> Hi Quanah,
>
> Am Di., 28. Aug. 2018 um 21:05 Uhr schrieb Quanah Gibson-Mount
> <quanah(a)symas.com>:
>> --On Tuesday, August 28, 2018 9:48 PM +0200 Karsten Heymann
>> <karsten.heymann(a)gmail.com> wrote:
>>
>> > Which one is the preferred one?
>>
>> Indeed, slapcat + slapadd is the preferred route.
>
> Great, so I was not too far off.
>
>> d) slapadd this second export to the rest of the new cluster
>
> I gess with no extra options regarding replication this time?
Correct. Can just use "-q" at this point.
>> * <http://www.openldap.org/its/index.cgi/?findid=8902>
>
> Ok, didn't know that.
>
> Thanks a lot. I performed a test import following your instructions
> and so far everything looks good.
> Karsten
Glad it's looking good. :) In the future, please keep replies on the list
unless they contain some type of sensitive info (passwords, etc). ;) This
helps ensure others have the possibility of making use of the information.
:)
Warm regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
5 years, 3 months
