Offline modification in replicated environment
by Ryan Tandy
When my (Debian's) users upgrade to 2.4.43 or later, if they use the ppolicy overlay and cn=config, I have to add the pwdMaxRecordedFailure attribute to the schema, otherwise slapd can't start.
Basic steps: slapcat the config database; a few lines of perl to add the new attribute, update the pwdPolicy object class, and strip out modifiersName and modifyTimestamp so they get regenerated; slapadd it back. No problem for a standalone system.
The config database might be replicated, though. For that, I'm also removing entryCSN from the schema entry I modify, and letting slapadd regenerate it. I'm not using -S with slapadd, so the reloaded entry is getting sid 000 every time.
I've tested master-slave and master-master setups, and this seems to be working as intended. But I'd like to ask the people here who have more experience with replication than I do: is this a bad plan? What could go wrong?
thanks,
Ryan
7 years, 7 months
Export issue after an DN change
by mdii
I'm having a weird issue with my OpenLDAP directory, maybe some of you had
a similar issue in the past and can point me in the right direction, at the
moment I have no idea where to start looking...
In my directory, the entities are listed in the ou=organisation branch,
where the key is the entity label and they have a hierarchic structure, for
example:
- ou=organisation
- ou=entity1,ou=organisation
- ou=entity2,ou=entity1,ou=organisation
- ou=entity3,ou=entity1,ou=organisation
- ou=entity4,=entity3,ou=entity1,ou=organisation
- ou=entity5,ou=organisation
- ...
The issue appears when there is a label change in one of the entities. In
this example I will change entity3 by entity33:
- ou=organisation
- ou=entity1,ou=organisation
- ou=entity2,ou=entity1,ou=organisation
- ou=entity33,ou=entity1,ou=organisation
- ou=entity4,=entity33,ou=entity1,ou=organisation
- ou=entity5,ou=organisation
- ...
When I'm using a directory browser, let's say ApacheDS, I have no trouble,
I can see the entire directory tree (as above).
My issue is the following:
- If I do a LDIF export (using the same ApacheDS), it doesn't export the
entity4 entry (or any other entity under entity33)
- If I do a Java application that uses a LDAP framework (Spring or
UnboundID in my case), I have the same problem, it doesn't see the entity4
entry
- I can do an entity4 LDIF export, it works well
Meanwhile there is a solution to this issue. If I do the series of
operations:
- LDIF export of entity4
- LDIF export of entity33
- LDIF export of entity1
- suppression of entity33 (witch includes all entries under it)
- Import of entity1
- Import of entity33
- Import of entity4
Once these operations completed, everything goes normal and entity4 will be
exported when I do an entity33 LDIF export.
One last detail, when I enter the enterprise, the issue was known, and it
was told me to export the parent entity of the one that had the label
change, that’s why I do the enetity1 export/suppression/import (not only
the entity33).
Do you have any idea of what's going on? At the moment I have no idea where
to start looking at, if I can change some settings or if it's an OpenLDAP
know bug.
I would like to thank you in advance for any help,
Best regards,
Marc
7 years, 7 months
Query regarding Openldap implementation
by Samrin S.N
Hi There,
I have a query on ldap_search_ext_s() API being used. This API is returning
operations error and by default the option LDAP_OPT_REFERRALS is default to
1.
I feel when we use this API, it tries and finds other referrals present in
the AD server configuration forest. Can you please help me in understanding
this API behaviour. I have found that even though the requested user is
found at one of the referral, again the search is done on other referrals
for the same user. What is the significance of trying to search the node in
other referrals.
Your help is highly appreciated.
--
Thanks,
Samrin
7 years, 7 months
How to enable search using wildcard characters
by PRATIK SINGAL
Hello All,
Can any one please help me how can i search using wild card character.
My base dn is "dc=example,dc=com" and i want to search all the records
having "telephone" attribute whose value is starting from 256*
Am using below verion of openldap
$OpenLDAP: slapd 2.4.40
Is there any changes which needs to be done in slapd.conf to enable
wildcard search
Regards,
Pratik
7 years, 7 months
memberuid value should be DN or RDN or both woks
by scn_73＠yahoo.com
All,
Openldap is complaining invalid dn. I doubt, it's for group members those memberuid don't have have DN and added as RDN. Like to know does memberuid should be DN or RDN works too.
slapd[4892]: conn=1629448 op=2180 do_search: invalid dn (member1)
slapd[4892]: conn=1629448 op=2181 do_search: invalid dn (memver2)
slapd[4892]: conn=1629448 op=2182 do_search: invalid dn (member2)
objectClass: posixGroup
objectClass: top
cn: g1
gidNumber: xxxx
memberUid: member1
memberUid: member2
memberUid: member3
- Sachin
7 years, 7 months
Best method to swap TLS cert/key/CA files
by ML mail
Hello,
I would like to swap my self signed certificate including CA, cert and key with a new set of CA, cert and key files on my OpenLDAP 2.4.31 master and replica servers. What would be the best way to achieve that? Can I simply run an ldapmodify with the new values and then restart slapd? Is it as easy as that or are there any pitfalls I should take care of?
Thank you in advance for your comments.
Regards
ML
7 years, 7 months
passwd, proxying, and idassert-authzFrom
by David Magda
Hello,
I have a master OpenLDAP server, with a bunch of slaves, and then Linux
clients talking to the slaves. We've used olcUpdateRef/updateref for a
while, but have a situation where we need to proxy connection on behalf of
clients via the slaves.
So we have configured a slapo-chain(5) overlay, with the following settings:
olcDbURI: ldap://10.0.0.555/
olcDbIDAssertBind: bindmethod=simple \
binddn="cn=update,dc=example,dc=ca" \
credentials=s3cr3t mode=self
olcDbRebindAsUser: TRUE
However, when users try to run passwd(1) (with pam_ldap.conf(5) having the
"pam_password exop" setting) they get:
> LDAP password information update failed: Strong(er) authentication required
only authenticated users may change passwords
> passwd: Permission denied
> passwd: password unchanged
On the master, we have:
> Apr 12 13:14:00 ops slapd[26119]: conn=16 fd=32 ACCEPT from
IP=111.222.333.444:59985 (IP=0.0.0.0:389)
> Apr 12 13:14:00 ops slapd[26119]: conn=16 op=0 BIND dn="" method=128
> Apr 12 13:14:00 ops slapd[26119]: conn=16 op=0 RESULT tag=97 err=0 text=
> Apr 12 13:14:00 ops slapd[26119]: conn=16 op=1 EXT
oid=1.3.6.1.4.1.4203.1.11.1
> Apr 12 13:14:00 ops slapd[26119]: conn=16 op=1 PASSMOD
> Apr 12 13:14:00 ops slapd[26119]: conn=16 op=1 RESULT oid= err=8
text=only authenticated users may change passwords
The (cn=update...) DN has an "authzTo" attribute set to
"{0}dn.regex:^uid=[^,]+,ou=People,dc=example,dc=ca".
I'm guessing I may need to set idassert-authzFrom (olc equiv?) to
something. Is this correct? If so, should it be restricted to ou=People?
If not, what am I missing?
Thanks for any info.
Regards,
David
7 years, 7 months
Re: Openldap vs 389
by Achilleas Mantzios
On 19/04/2016 13:41, Emmanuel Lécharny wrote:
> Le 19/04/16 11:39, Achilleas Mantzios a écrit :
>> On 19/04/2016 12:20, Emmanuel Lécharny wrote:
>>> Le 19/04/16 10:47, Achilleas Mantzios a écrit :
>>>> Hello,
>>>>
>>>> I have been testing sporadically openldap two years now, including
>>>> many advanced features, sql, ppolicy, etc we are currently evaluating
>>>> openldap along with redhat's 389 for enterprise use as RBAC, on which
>>>> we will built upon our existing infrastructure. We want to have full
>>>> password policy enabled, in order to meet requirements for passing SOX
>>>> (Sarbanes Oxley) compliance.
>>>> 389's documentation is lousy, I haven't tried anything exotic (sql,
>>>> etc) with it, the reason we are looking at it is because it is favored
>>>> by kolab.org and likely to come as standard in future kolab versions.
>>>> So I would like your opinion on this. Pros/Cons to choose openldap or
>>>> 389 directory server as our long term strategic decision?
>>>>
>>> If you are interested in RBAC, know that there is a Java API that
>>> implements RBAC at http://directory.apache.org/fortress/ (1.0.0 have
>>> just been released last week). It works with OpenLDAP as a backend (and
>>> some other LDAP server too).
>> Hi I had talked with a SYMAS person some years ago regarding fortress,
>> this is also hosted by openldap : http://www.openldap.org/fortress/
>> So who manages fortress?
> It has moved to the Apache Foundation 2 years ago.
Thanx for the insight.
>
>
>> By the test we had done with openldap it seemed that marginally we
>> could meet our password policy requirements.
> Here, you will have to tell us more about your requirements.
Right, we have an inhouse application running on Java EE, which we have been developing for the last 16 years. We use mostly classic form-based j2ee declarative security. We have been using IBM Lotus
Notes Domino Server and its bundled LDAP server, by writing our own login module for Jboss. But lotus's LDAP is of limited potential. Now we need to have the following features :
- support password strength and also communicate relevant error codes/messages back to the calling client (e.g. jboss login module)
- handle correctly while in period of passwd expiration warning (error codes/messages)
- handle correctly after period of passwd expiration, but within the grace limit (error codes/messages)
- support password history (error codes/messages)
- handle correctly after period of passwd expiration, and also after grace limit (error codes/messages)
- account explicitly locked (error codes/messages)
- handle pwdMustChange & pwdReset (error codes/messages)
- account explicitly locked after pwdMaxFailure (error codes/messages)
According to some tests we had done back in 2014, we had it all covered, in theory. Our idea was to have some supplementary roles assigned to the user, denoting of any outstanding state of the
account, and then add this role to the user, inside the login module, and then use an hybrid approach of declarative security + some filters + some programmatic security to allow the user to have a
full RBAC experience
--
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt
7 years, 7 months
Re: Openldap vs 389
by Achilleas Mantzios
On 19/04/2016 12:20, Emmanuel Lécharny wrote:
> Le 19/04/16 10:47, Achilleas Mantzios a écrit :
>> Hello,
>>
>> I have been testing sporadically openldap two years now, including
>> many advanced features, sql, ppolicy, etc we are currently evaluating
>> openldap along with redhat's 389 for enterprise use as RBAC, on which
>> we will built upon our existing infrastructure. We want to have full
>> password policy enabled, in order to meet requirements for passing SOX
>> (Sarbanes Oxley) compliance.
>> 389's documentation is lousy, I haven't tried anything exotic (sql,
>> etc) with it, the reason we are looking at it is because it is favored
>> by kolab.org and likely to come as standard in future kolab versions.
>> So I would like your opinion on this. Pros/Cons to choose openldap or
>> 389 directory server as our long term strategic decision?
>>
> If you are interested in RBAC, know that there is a Java API that
> implements RBAC at http://directory.apache.org/fortress/ (1.0.0 have
> just been released last week). It works with OpenLDAP as a backend (and
> some other LDAP server too).
Hi I had talked with a SYMAS person some years ago regarding fortress, this is also hosted by openldap : http://www.openldap.org/fortress/
So who manages fortress?
By the test we had done with openldap it seemed that marginally we could meet our password policy requirements.
>
> Regarding OpenLDAP, obviously, this list is clearly biased. Now, let's
> see what you can find on the Internet :
>
> http://www.slideshare.net/ldapcon/benchmarks-on-ldap-directories
>
Thanx!
>
--
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt
7 years, 7 months
