Re: Tuning number of entries sent during syncrepl?
Hi, May be the olcLimits parameter at consumer side. try also delta syncrepl: http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl This feature require accesslog enabled. Hope this help. Cheers. Le 20/11/2015 12:52, Bannister, Mark a écrit : It takes about 10 minutes to synchronise about 300,000 entries across the WAN, but the WAN isn’t that slow here, I can transfer an LDIF file much faster than that over NFS. Before LDAPCon last week, I had been working on a solution to this problem, where I would get the master server to dump its contents once a day to NFS, and then replicas could build initially from that. It was taking quite a bit of work, and it was slightly annoying that I needed to jump through these hoops. Last week I was speaking with someone at LDAPCon who told me he had come across the same problem, and it turned out to be something to do with the maximum number of entries that can be transferred in one go? - although I may have misheard this, so please forgive me if details are not entirely accurate. But apparently this is tunable, and if I increase it, my 300,000 entries will replicate much much faster. Any ideas? Sorry I’m a bit sketchy on details. Thanks, Mark. NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies; do not disclose, use or act upon the information; and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing. -- *Abdelhamid Meddeb* http://www.meddeb.net smime.p7s Description: Signature cryptographique S/MIME
Re: Getting around the single-threaded syncrepl model?
I think this effectively allows to better use of server resources, but what about the reliability of the synchronization ? IMHO, You should be careful about intra-server synchronization Le 20/11/2015 12:36, Bannister, Mark a écrit : 2 - If my master server has 40 cores, would there be mileage in setting up a number of slapd processes (say 10) on the same host, bound to different sockets, all acting as first-level replicas, and then all the replicas fanning out across the WAN synchronise from these processes rather than from the master process? That would be a way, I suppose, of getting the master server to make better use of the available cores to get updates out quicker? -- *Abdelhamid Meddeb* http://www.meddeb.net smime.p7s Description: Signature cryptographique S/MIME
Re: Tuning number of entries sent during syncrepl?
I'm sorry. At provider side Le 22/11/2015 09:40, Abdelhamid Meddeb a écrit : Hi, May be the olcLimits parameter at consumer side. try also delta syncrepl: http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl This feature require accesslog enabled. Hope this help. Cheers. Le 20/11/2015 12:52, Bannister, Mark a écrit : It takes about 10 minutes to synchronise about 300,000 entries across the WAN, but the WAN isn’t that slow here, I can transfer an LDIF file much faster than that over NFS. Before LDAPCon last week, I had been working on a solution to this problem, where I would get the master server to dump its contents once a day to NFS, and then replicas could build initially from that. It was taking quite a bit of work, and it was slightly annoying that I needed to jump through these hoops. Last week I was speaking with someone at LDAPCon who told me he had come across the same problem, and it turned out to be something to do with the maximum number of entries that can be transferred in one go? - although I may have misheard this, so please forgive me if details are not entirely accurate. But apparently this is tunable, and if I increase it, my 300,000 entries will replicate much much faster. Any ideas? Sorry I’m a bit sketchy on details. Thanks, Mark. NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies; do not disclose, use or act upon the information; and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing. -- *Abdelhamid Meddeb* http://www.meddeb.net smime.p7s Description: Signature cryptographique S/MIME
Re: Controlling rootdn access
Hi, Le 07/11/2015 11:38, Michael Ströder a écrit : Abdelhamid Meddeb wrote: Be careful with this kind of change and keep in mind that after deleting olcRooPW you don't have a true rootdn at all. A true rootdn don't need any explicitly right access by the ACLs, but the pseudo (new) rootdn need it, and if no rule grant him the access the operation fail. There is no such thing as a pseudo rootdn. "pseudo rootdn" is not a thing of openldap or ldap, it's a term used to simpify explanation. I'm sorry for my explanation which was not detailed enough. a "thing" designed by "pseudo root dn" is an arbitrary dn entry who has *full* access to all "things" of database and config database. 1. Either you have rootdn directive set or not. Note: It is needed for some overlays. 2. Either you have rootpw directive set or not. I always use slapd -h "ldapi://.." omit rootpw and have the following directive: authz-regexp "gidnumber=0\\+uidnumber=0,cn=peercred,cn=external,cn=auth" "cn=root,dc=example,dc=com" Can work also if the *change* of configuration follows the indicated step by step approach . Then user root can always locally authenticate without a password like this: ldawhoami -H ldapi:// -Y EXTERNAL Ciao, Michael. Cheers. -- *Abdelhamid Meddeb* http://www.meddeb.net smime.p7s Description: Signature cryptographique S/MIME
Re: Controlling rootdn access
Hi, Be careful with this kind of change and keep in mind that after deleting olcRooPW you don't have a true rootdn at all. A true rootdn don't need any explicitly right access by the ACLs, but the pseudo (new) rootdn need it, and if no rule grant him the access the operation fail. IMHO, a carefully way to do this is: 1/ with truerootdn bind, add a (pseudo) rootdn entry (dn:cn=pseudorootdn,o=organization) who different from true rootdn (dn:cn=trueroodn,o=organization and olcRootDN=cn=trueroodn,o=organization) 2/ with truerootdn bind, grant all access to all database and config database. A bit of test is welcome at this level 3/ With pseudorootdn bind, delete olcRootPW 4/ Restrict access to cn=pseudorootdn,o=organization by peer as indicated in the linked page. Cheers Le 05/11/2015 07:55, Michael Hierweck a écrit : Hi all, I'm trying to improve security by restricting rootdn access to localhost. See: http://www.openldap.org/doc/admin24/access-control.html#Controlling%20rootdn%20access But I can't delete the olcRootPW attribute from the olcDatabase object: ldap_modify: Inappropriate matching (18) additional info: modify/delete: olcRootPW: no equality matching rule I suppose the access restriction to the rootdn's userPassword attribute does not take effect as the provided password will be compared against the olcRootPW attribute (directly). Thanks in advance Michael -- *Abdelhamid Meddeb* http://www.meddeb.net smime.p7s Description: Signature cryptographique S/MIME
Re: BP build OpenLDAP and lmdb packages
Hi, Thanks to all. Now I anderstand more about that It's a bit unfortunate that it's so. But most important is reliability and performance. Cheers. Le 27/09/2015 23:07, Howard Chu a écrit : > > OpenLDAP source code is released as a single unit. This situation is no > different than building slapd itself against libldap_r. If you split > things apart and mix versions, you can potentially break them. > Le 28/09/2015 17:58, Quanah Gibson-Mount a écrit : --On Monday, September 28, 2015 10:26 AM +0200 Michael Ströder <mich...@stroeder.com> wrote: Hmm, in the long run I'd like to see a single liblmdb being installed with the accompanying tools system-wide just like the BDB libs/tools. I understand that this would limit the freedom of developing/shipping an OpenLDAP-specific "fork" in the OpenLDAP sources. Can't say I've necessarily seen that done with BDB either... Like RHEL and debian tend to have multiple bdb versions available, with the tools named things like db42_dump etc, so that the version specific utilities can be used. On the LMDB side, we're missing things like libtool versioning that would allow this to be more easily possible. Also, having it so 0.9.x is backwards compatible with 0.9.y, y < x, would make things a bit easier to deal with as well. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration -- *Abdelhamid Meddeb* http://www.meddeb.net
Re: BP build OpenLDAP and lmdb packages
Hi, +1 Statically link is a bad idea in this case, IMHO. Le 26/09/2015 20:39, Quanah Gibson-Mount a écrit : --On Saturday, September 26, 2015 8:11 PM +0200 Michael Ströder <mich...@stroeder.com> wrote: HI! I wonder what's considered best practice for building OpenLDAP and lmdb packages e.g. for a Linux distribution. Fortunately lmdb seems to be leveraged by more and more other software. So Linux distributions start to ship lmdb libs and tools as separate packages. 1. Do I have a chance to build OpenLDAP against those packages? Which releases have to be aligned? 2. Or should I link back-mdb statically into slapd when producing OpenLDAP packages? This would probably also require to build separate version of the mdb tools. OpenLDAP should only ever be statically linked to the version of liblmdb it ships with. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration -- *Abdelhamid Meddeb* http://www.meddeb.net
Re: ACLs whont work
Hi, +1 and.. A good way to think the acl rules construction is to say: 1/ the rules lines are scanned from top to bottom 2/ Every line is scanned from left to right 3/ When ldap query match one rule the scan process is *immediately* stopped. In this this case: "access to * by * write by anonymous none" "by anonymous" is *never* scanned because it is at the right of "by *" who match everything Cheers. Le 23/09/2015 11:29, Michael Ströder a écrit : Dario Zanzico wrote: On Wed, Sep 23, 2015, at 10:36 AM, Fischer, Johannes wrote: I struggle with the ACLs, I whant a special account to check the username and PW of the entries on the LDAP-server. Therefore I’ve written the following in the slapd.conf file: access to attrs=userPassword by dn="cn=authenticate,dc=vfk,dc=ldap,dc=com" write by self write by anonymous none this acl makes everyone able to write everything (except the password that can be written by cn=authenticate and self), and makes it impossible to bind not-anonimously if you want users to be able to authenticate you shoud give 'anonymous' users auth permissions to the userpassword attr: access to attrs=userpassword # allow connections to bind as user by anonymous auth # allow self password change by self write # allow cn=authenticate password change by dn="cn=authenticate,dc=vfk,dc=ldap,dc=com" write Also note that "write" also includes "read" access which is not necessary. Better use privileges. I've compiled some of my usual simple patterns into this example config: https://build.opensuse.org/package/view_file/home:stroeder:branches:network:ldap/openldap2/slapd.conf.example?expand=1 YMMV. So everybody caring for real access control should really dive into slapd.access(5) [1]. [1] http://www.openldap.org/software/man.cgi?query=slapd.access Ciao, Michael. -- *Abdelhamid Meddeb* http://www.meddeb.net
Re: ppolicy and pwdGraceUseTime
Hi, I think you are confusing between the password expiration and account lockout. If your account is locked after several failed attempts to bind, you cannot modify your passwords. Cheers. Le 28/08/2015 18:37, Craig White a écrit : Openldap 2.4.39 Adding in policy in already running OpenLDAP installation. Mostly functional – I was locked out after failed password attempts as expected. Existing user with password beyond expiration is an issue. It is extended grace logins as expected but when I try to change the password, I get an error which appears to be “error 16 – modify/delete: pwdGraceUseTime: no such attribute” -- *Abdelhamid Meddeb* http://www.meddeb.net smime.p7s Description: Signature cryptographique S/MIME
Re: RHEL7 OpenLDAP server is not enforcing password expirations
Hi, No one. If password expire in openldap server, the client (whatever is it) bind *fail*. Thats all. Cheers. Le 28/08/2015 00:56, Real, Elizabeth (392K) a écrit : Hello, I’ve done a lot or research and re-read the OpenLDAP configuration guides but I cannot get my OpenLDAP 2.39 server to not allow users with expired passwords to login to ldap enabled clients. What directive in the /etc/pam.d/ files controls the users password expiration attribute? pam_unix or pam_ldap? -- *Abdelhamid Meddeb* http://www.meddeb.net smime.p7s Description: Signature cryptographique S/MIME
Re: Multi-master syncrepl config: excluding olcSaslHost from replication
Hi, How about delta-syncrepl ? http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl%20replication Cheers. Le 21/08/2015 21:31, Kyle Brantley a écrit : I'm working on a full multi-master slapd setup, where both the cn=config database as well as the actual database are fully replicated. All access to the slapd instances is gated with GSSAPI (the only notable exception being the syncrepl users, which I'm working on converting over to GSSAPI anyway). However, I need to be able to configure olcSaslHost on a per-server basis. Server A will have a different value for olcSaslHost than server B will. While I want to replicate cn=config, I don't want to replicate the olcSaslHost attribute. I've tried two things, and neither have worked: 1) Configuring exattrs=olcSaslHost in the olcSyncrepl statements for cn=config. * This allows me to configure the attribute, but as soon as there is any other change to cn=config, it wipes the attribute out across all of the nodes. 2) Updating the ACL for the syncrepl user to not have access to the olcSaslHost attribute. * Unfortunately, this has similar behavior to the above: making a change on one node will wipe the olcSaslHost attribute out of all of the nodes. How best can I go about doing this? I was hoping that olcSaslRealm was multi-value and could be configured in a manner similar to olcServerID, but that isn't the case. I was hoping that denying access to the attributes (via ACL or olcSynrepl config) would make the syncrepl engine ignore the attribute, but because it can't see it on the node where the attribute was changed, but it can see it on the downstream nodes, it wipes the attribute out entirely. Any help / suggestions welcome. Thanks, --Kyle -- *Abdelhamid Meddeb* http://www.meddeb.net smime.p7s Description: Signature cryptographique S/MIME
Re: OLC ppolicy
Hi,
ppolicy is the right name, however it is invoked two times in your
olcModuleLoad param, keep only one.
According reported configuration, only three params of password policy
are defined:
1/ olcPPolicyHashCleartext: TRUE
2/ olcPPolicyUseLockout: FALSE
3/ pwdMinLength: 12
what you should check to test:
1/ Password is hashed (SSHA by default) when it's provided as cleartext
2/ ldap entry never locked after several failed attempt to bind
3/ Password modification rejected with error message when length of new
one is less than 12 characters.
That's what empirically these commands do.
*Important*
Be careful, rootdn bypass passwored policy.
Hope this help
Cheers.
Le 20/08/2015 16:57, Jeremy Trammell - DLA a écrit :
On 08/20/2015 07:50 AM, Dieter Klünter wrote:
Am Wed, 19 Aug 2015 13:07:11 -0700
schrieb Jeremy Trammell - DLA jtramm...@deeplearninganalytics.com:
Greetings,
I'm trying to set up a very simple LDAP server using OpenLDAP (via
OLC) and it seems hopeless. The sticking point is ppolicy. I have
followed several online guides
(http://www.ryanfrantz.com/posts/openldap-implementing-the-password-policy-overlay/,
https://www.oostergo.net/node/85, to name a few), all of which seem
to essentially detail the same procedure, and have met with no
success. Whilst following those instructions, I receive no error
messages. All commands complete successfully and do not indicate
failures of any kind. Looking at the cn=config and target DITs, all
data seems to have been imported as expected. Despite that fact,
passwd follows a mystery policy which bears no resemblance to the
policy that I have specified, and ldappasswd follows no policy at
all you can do whatever you want. Is there some way for me to
empirically determine what these commands are doing, and why my
policy does nothing? Thanks in advance...
cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModuleLoad: {0}ppolicy.la
olcModuleLoad: {1}back_hdb
olcModuleLoad: {2}ppolicy
olcModulePath: /usr/lib/ldap
The module names are not correct.
Hint: check /usr/lib/ldap for correct module names.
-Dieter
Okay, so what is the correct module name? It's listed as ppolicy in
/usr/lib/ldap:
lrwxrwxrwx 1 root root 20 May 25 10:09 ppolicy-2.4.so.2 -
ppolicy-2.4.so.2.8.3
-rw-r--r-- 1 root root 39328 May 25 10:09 ppolicy-2.4.so.2.8.3
-rw-r--r-- 1 root root954 May 25 10:08 ppolicy.la
lrwxrwxrwx 1 root root 20 May 25 10:09 ppolicy.so -
ppolicy-2.4.so.2.8.3
--
*Abdelhamid Meddeb*
http://www.meddeb.net
smime.p7s
Description: Signature cryptographique S/MIME
Re: OLC ppolicy
Hi all, module-name | module-name.la do same thing: link a system library. .. at the end of the day. Really, there is a technical diff, first one *dynamically* link the library (using module-name.so file), second one *statically* link the library (using module-name.la file). what should we do is using *only* one of these alternatives at the same time. Cheers. Le 22/08/2015 09:10, Dieter Klünter a écrit : The module names are not correct. Hint: check /usr/lib/ldap for correct module names. -Dieter Okay, so what is the correct module name? It's listed as ppolicy in /usr/lib/ldap: lrwxrwxrwx 1 root root 20 May 25 10:09 ppolicy-2.4.so.2 - ppolicy-2.4.so.2.8.3 -rw-r--r-- 1 root root 39328 May 25 10:09 ppolicy-2.4.so.2.8.3 -rw-r--r-- 1 root root954 May 25 10:08 ppolicy.la lrwxrwxrwx 1 root root 20 May 25 10:09 ppolicy.so - ppolicy-2.4.so.2.8.3 back_hdb.la ppolicy.la -Dieter -- *Abdelhamid Meddeb* http://www.meddeb.net smime.p7s Description: Signature cryptographique S/MIME
Re: How to import user certificates in OpenLDAP?
Hi all Le 16/07/2015 15:19, Howard Chu a écrit : It's much like the choice between fruits veg you grew in your own garden, vs buying a frozen microwavable dinner. Reliance on packaged/processed stuff will catch up to you in the long run. great !! Howard, the opensource's philosoph. -- *Abdelhamid Meddeb* http://www.meddeb.net smime.p7s Description: Signature cryptographique S/MIME
Re: Syncrepl issue with one node
Hi,
In the same situation I've solved the issue by dropping data in the
server 1, and retrieve them from the other servers:
Server 1:
1. Stop
2. Drop data in db (keep the DB_CONFIG file)
3. Start it
Hope this helps.
Cheers.
Le 11/06/2015 15:59, espe...@oreillyauto.com a écrit :
From: Quanah Gibson-Mount qua...@zimbra.com
To: espe...@oreillyauto.com, openldap-technical@openldap.org
Date: 06/10/2015 04:09 PM
Subject:Re: Syncrepl issue with one node
b) Not enough information provided here to go on. Are all server IDs
unique? Are all syncrepl clauses unique per DB? Personally I've never
found ntpd particularly good at keeping clocks in sync. I've generally
resorted to running ntpdate frequently out of cron, particularly for VMs.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
Zimbra :: the leader in open source messaging and collaboration
All of the nodes have unique ID's:
olcServerID: 1 ldap://tn-ldap-a-1.mydomain.com
olcServerID: 2 ldap://tn-ldap-a-2.mydomain.com
olcServerID: 3 ldap://tn-ldap-a-3.mydomain.com
Each database has it's one Syncrepl clause 001, 002, 003 rids sync
configuraiton changes, and 004,005, 006 sync the user data.
All configuration changes replicate with no issue. Data changed on servers
23 replicate between each other, but server 1 gives the CSN too old error.
If I change user data on node 1 it replicates to nodes 2 3 with no
issues.
I stopped the ntp service on the offending node and ran ntpdate-debian. I
still get the CSN too old errors in the logs.
Is there a setting in the syncrepl that I can use to expand out the window
for a CSN age? Below is the configuration I have for user data.
olcSyncrepl: {0}rid=004 provider=ldap://tn-ldap-a-1.mtdomain.com
binddn=uid=admin,dc=mydomain,dc=com bindmethod=simple credentials=secret
searchbase=dc=mydomain,dc=com type=refreshAndPersist retry=5 5 5 +
timeout=1
Thank you,
Eric
This communication and any attachments are confidential, protected by
Communications Privacy Act 18 USCS § 2510, solely for the use of the intended
recipient, and may contain legally privileged material. If you are not the
intended recipient, please return or destroy it immediately. Thank you.
--
*Abdelhamid Meddeb*
http://www.meddeb.net
smime.p7s
Description: Signature cryptographique S/MIME
Re: why is userPassword transferred binary?
Hi,
Both attributes are in plain text.
ldapsearch, always *encode* userPassword value in base64. Try:
echo Z290Y2hhCg== | openssl base64 -d
The result is gotcha too.
Cheers.
Le 11/06/2015 09:48, Jephte Clain a écrit :
hello,
just wondering: when I ldapsearch the userPassword attribute, it is
returned as binary:
$ ldapsearch -LLL -H ldap://xxx:389/; -x -D xxx -W (uid=xxx)
userPassword
dn: uid=xxx,dc=domain,dc=tld
userPassword:: Z290Y2hhCg==
however, I created a new attribute with the same schema as userPassword:
attributetype ( runUniv:1.1.2
NAME 'runUnivPassword'
DESC 'RFC2256/2307 password for special needs'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
when I search this attribute, it is returned as text:
$ ldapsearch -LLL -H ldap://xxx:389/; -x -D xxx -W (uid=xxx)
runUnivPassword
dn: uid=xxx,dc=domain,dc=tld
runUnivPassword: gotcha
so my question is: does ldapsearch process userPassword as a special
case and ask for binary transfer type?
or does slapd return userPassword as binary by default? if so, how do I
configure runUnivPassword to be handled the same?
thanks in advance. best regards,
--
*Abdelhamid Meddeb*
http://www.meddeb.net
smime.p7s
Description: Signature cryptographique S/MIME
Re: Openldap password problems
Hi all,
Right now we may say, IMHO, this is a strongest encryption available in
POSIX systems.
SHA-1 ({SSHA}, default in OpenLDAP) is good one also (IMHO), to crack it
you must mobilize many means. The question is: does the degree of
confidentiality of data deserve to opt for a bit more complicated setup ?
Cheers.
Le 15/05/2015 20:02, Albert Braden a écrit :
This is what I use. I'm not sure this is the highest possible security but it did fix the
ignore anything over 8 characters issue.
password-hash {CRYPT}
password-crypt-salt-format $6$%.12s
-Original Message-
From: openldap-technical [mailto:openldap-technical-boun...@openldap.org] On
Behalf Of Michael Ströder
Sent: Friday, May 15, 2015 5:08 AM
To: Quanah Gibson-Mount; openldap-technical@openldap.org
Subject: Re: Openldap password problems
Quanah Gibson-Mount wrote:
Setting the default to {CRYPT} is a security nightmare,
Such a general statement is non-sense without taking a closer look at which
crypt scheme is really used.
Consult your local crypt(3) man page to see whether crypt schemes like $6$
or $2b$ are supported on your system which are definitely stronger than
simple {SSHA}. Then use password-crypt-salt-format to make use of such a crypt
scheme.
Ciao, Michael.
--
*Abdelhamid Meddeb*
http://www.meddeb.net
smime.p7s
Description: Signature cryptographique S/MIME
Re: How to check the login history of users on openldap
You are probably right, thanks. Le 16/05/2015 10:38, Bjørn Ruberg a écrit : On 16. mai 2015 10:00, Abdelhamid Meddeb wrote: Hi, Start here: http://www.openldap.org/doc/admin24/monitoringslapd.html And see particularly here: http://www.openldap.org/doc/admin24/monitoringslapd.html#Connections Alternatively you can use log file of slapd with some text processor like perl or shell script. Sounds like the access log overlay is more what the OP is looking for. http://www.openldap.org/doc/admin24/overlays.html#Access%20Logging -- *Abdelhamid Meddeb* http://www.meddeb.net smime.p7s Description: Signature cryptographique S/MIME
Re: How to check the login history of users on openldap
Hi, Start here: http://www.openldap.org/doc/admin24/monitoringslapd.html And see particularly here: http://www.openldap.org/doc/admin24/monitoringslapd.html#Connections Alternatively you can use log file of slapd with some text processor like perl or shell script. Cheers. Le 15/05/2015 18:47, Peng Yu a écrit : Hi, I setup ubuntu servers to use an openldap for login authentication. I want to check who have logged in all the servers. A logic place to check is at the central openldap server. But I am not sure how to do. Could any of you let me know? -- *Abdelhamid Meddeb* http://www.meddeb.net smime.p7s Description: Signature cryptographique S/MIME
Re: ppolicy and ACL question
Hi, 1. If you can do that I think this is a bug in ldappasswd, pwdReset used to force user to change its password *only one time*. 2. No 3. manage access gives administrative privilege, while write does not allow it. administrative privilege allow modifying some attributes usually can (and should) not be modified. where the administrative term (e.g. entryUUID). You may find more details about that in https://tools.ietf.org/html/draft-zeilenga-ldap-relax-03 Cheers. Le 13/05/2015 04:06, Harmandeep Kaur a écrit : Hello folks, I have a quick query, I'm using openldap with ppolicy. I'm using following ACL just to test things right, I came across the issue, for which I'm unable to find appropriate answers: ACL used: --- access to * by * manage --- 1. How to restrict ldappasswd command to clear the pwdReset flag to user's entry ? 2. Can some other users (member of group) can work rootdn (bypass ppolicy like rootdn but it should apply to their account itself) ? 3. Other question is about ACL is What's the difference between ACL write and manage access write =wrscdx needed to modify/rename manage=mwrscdxneeded to manage I'm not able to determine what access manage gives over and above write access. I didn't find much info at openldap.org http://openldap.org access-control section. Thank you. Regards, -- *Abdelhamid Meddeb* http://www.meddeb.net smime.p7s Description: Signature cryptographique S/MIME
Re: idassert-bind seems to ignore binddn
what happen if you add: idassert-authzFrom dn.regex:.* to your configuration ? Le 01/05/2015 19:48, Ryan Lovett a écrit : Note that I can get access to the privileged attributes if the ldapsearch client binds to the proxy using a rootdn/rootpw, e.g. rootdn cn=proxy,dc=company,dc=com rootpw proxypass idassert-bind bindmethod=simple binddn=uid=my_id,ou=my_dept,dc=company,dc=com credentials=mypass $ ldapsearch ... -D cn=proxy,dc=company,dc=com -W Ryan On Fri, May 1, 2015 at 9:58 AM, Ryan Lovett r...@berkeley.edu mailto:r...@berkeley.edu wrote: According to http://www.openldap.org/faq/data/cache/532.html, idassert-authzFrom is not needed in this case. Here is the example: To allow (dumb) clients that do not perform bind to access servers that require bind (and some ssf) by asserting some static identity (the dn:dn, or even the anonymous mode, to implement the sandbox user described above) without any idassert-authzFrom rule in place: databaseldap suffix dc=example,dc=com uri ldap://ldap.example.com http://ldap.example.com idassert-bind bindmethod=simple binddn=cn=Proxy,dc=example,dc=com credentials=proxy authzID=dn:cn=Sandbox,dc=example,dc=com If no authzID is given, and mode is set to none (for instance because the remote server does not support the proxyAuthz control), the clients will be authorized as cn=Proxy,dc=example,dc=com even if they actually connected anonymously to the proxy. Beware that this may be a significant security breach, if that identity is granted anything but anonymous read privileges. Ryan On Fri, May 1, 2015 at 12:28 AM, Abdelhamid Meddeb abdelha...@meddeb.net mailto:abdelha...@meddeb.net wrote: Hi, In addition to ancient version, and according to reported configuration you are missed idassert-authzFrom setting. more details in slapd.conf(5). Without this parameter you may have this issue. Cheers. Le 01/05/2015 03:25, Quanah Gibson-Mount a écrit : --On Thursday, April 30, 2015 6:32 PM -0700 Ryan Lovett r...@berkeley.edu mailto:r...@berkeley.edu wrote: Hello, I've setup a simple proxy so that local LDAP clients can get access to protected attributes on a remote server. My proxy is slapd 2.4.31 with What am I doing wrong? Any advice is greatly appreciated! The first thing you're doing wrong is running a version of OpenLDAP that is so ancient. OpenLDAP 2.4.31 Release (2012/04/21) I.e., it's over 3 years old. There have been multiple fixes to slapd-ldap since that release. This one in particular may be related: OpenLDAP 2.4.33 Release (2012/10/10) Fixed slapd-ldap idassert bind handling (ITS#7403) --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration -- *Abdelhamid Meddeb* http://www.meddeb.net -- *Abdelhamid Meddeb* http://www.meddeb.net smime.p7s Description: Signature cryptographique S/MIME
Re: idassert-bind seems to ignore binddn
Hi, In addition to ancient version, and according to reported configuration you are missed idassert-authzFrom setting. more details in slapd.conf(5). Without this parameter you may have this issue. Cheers. Le 01/05/2015 03:25, Quanah Gibson-Mount a écrit : --On Thursday, April 30, 2015 6:32 PM -0700 Ryan Lovett r...@berkeley.edu wrote: Hello, I've setup a simple proxy so that local LDAP clients can get access to protected attributes on a remote server. My proxy is slapd 2.4.31 with What am I doing wrong? Any advice is greatly appreciated! The first thing you're doing wrong is running a version of OpenLDAP that is so ancient. OpenLDAP 2.4.31 Release (2012/04/21) I.e., it's over 3 years old. There have been multiple fixes to slapd-ldap since that release. This one in particular may be related: OpenLDAP 2.4.33 Release (2012/10/10) Fixed slapd-ldap idassert bind handling (ITS#7403) --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration -- *Abdelhamid Meddeb* http://www.meddeb.net smime.p7s Description: Signature cryptographique S/MIME
Re: modifying cn=config with ldapmodify
Hi, In your ssl.ldif file there is a *blank* line too after changetype: modify This is not reported in your first post but it apear in seconde one. I have reproduced the same symptoms with this empty line More details bellow Cheers. Le 29/04/2015 12:56, Robert Munn a écrit : My replies inline... On Apr 26, 2015, at 2:28 AM, Abdelhamid MEDDEB abdelha...@meddeb.net mailto:abdelha...@meddeb.net wrote: Hi, Le 25/04/2015 15:10, Robert Munn a écrit : I have been trying to replace the SSL cert settings on my OpenLDAP instance running on Ubuntu using ldapmodify. I followed directions on the Ubuntu wiki: https://help.ubuntu.com/lts/serverguide/openldap-server.html#openldap-tls using a modified ldif file for the replace: |dn: cn=config changetype: modify replace: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem - replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/ldap01_slapd_cert.pem - replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/ldap01_slapd_key.pem| |All right| Empty line is not reported here. When it didn’t work on my existing instance I built a new instance in a new Ubuntu VM (14.04) and tried the original directions from Ubuntu. That did not work either. May be you've missed some settings at build time like --with-tls I installed OpenLDAP using apt. The .deb package must include TLS because I added the certificates manually. The ldapmodify command executes correctly but it seems that the change is not registered by the server. This is the case in both the new instance and the old instance of OpenLDAP. No error message like Insufficient access (50) ? and you should check the write (manage)rights to cn=config database. The command I ran (as sudo) and the message: ldapmodify -Y EXTERNAL -H ldapi:/// -f ssl.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry cn=config” and ssl.ldif : dn: cn=config changetype:modify replace: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/CAcert - replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/cert - replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/cert.key But we show it here, and content changes (strangely) the cn=config.ldif last modified timestamp, but do nothing realy cn=config.ldif is being modified by the ldapmodify process, I verified that by changing file permissions on cn=config.ldif, running the ldapmodify command, and then checking cn=config.ldif. ldapmodify updated the timestamp and file permissions on the file. The file changed, but the configuration changes in ssl.ldif were not made in cn=config.ldif. I ended up replacing the values (or adding them in the new instance) in the /etc/ldap/slapd.d/cn=config.ldif file manually. Making the changes manually and restarting slapd works, but my understanding was that changes to cn=config should be made through ldapmodify. Bad practice, it's best to avoid. Yes, and when I can modify the configuration using ldapmodify, I will no longer make the changes manually. I found a note about enabling logging using ldapmodify: https://help.ubuntu.com/lts/serverguide/openldap-server.html logging.ldif: dn: cn=config changetype: modify replace: olcLogLevel olcLogLevel: stats ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f logging.ldif I executed this command on my first instance and it added the logging to cn=config. I executed this command on the second instance, where olcLogLevel already existed, and it did not alter the log level. I have also been experimenting with this script: https://github.com/cepharum/slapd-config With it, I was able to delete the TLS entries from cn=config: slapd-config raw delete cn=config olcTLSCACertificateFile 1 but when I tried to add the entries back, I got this error: slapd-config raw insert cn=config olcTLSCACertificateFile 1 /etc/ssl/certs/cert.pem modifying entry ldap_modify: Server is unwilling to perform (53) additional info: modify upon the root DSE not supported I have not looked at the details but it seems that there is a bug in this script. (modifying entry ) I was able to change the olcLogLevel back to its original state vi ldapmodify, so maybe there is something particular about the TLS entries, perhaps having to do with permissions on the certs and keys themselves? I have come across this bug in several forums and have yet to see someone who solved it in the “correct” manner using ldapmodify. Robert I also found a tech note at CentOS: https://www.centos.org/docs/5/html/CDS/cli/8.0/Configuration_Command_File_Reference-Core_Server_Configuration_Reference-Accessing_and_Modifying_Server_Configuration.html in section 2.2.2.2 that indicates changes to cn=config will be ignored: If an attribute is added to |cn=config|, the server ignores it. So am I mistaken? Do I need to do
Re: modifying cn=config with ldapmodify
Hi, Le 25/04/2015 15:10, Robert Munn a écrit : I have been trying to replace the SSL cert settings on my OpenLDAP instance running on Ubuntu using ldapmodify. I followed directions on the Ubuntu wiki: https://help.ubuntu.com/lts/serverguide/openldap-server.html#openldap-tls using a modified ldif file for the replace: |dn: cn=config changetype: modify replace: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem - replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/ldap01_slapd_cert.pem - replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/ldap01_slapd_key.pem| |All right| When it didn’t work on my existing instance I built a new instance in a new Ubuntu VM (14.04) and tried the original directions from Ubuntu. That did not work either. May be you've missed some settings at build time like --with-tls The ldapmodify command executes correctly but it seems that the change is not registered by the server. This is the case in both the new instance and the old instance of OpenLDAP. No error message like Insufficient access (50) ? and you should check the write (manage)rights to cn=config database. I ended up replacing the values (or adding them in the new instance) in the /etc/ldap/slapd.d/cn=config.ldif file manually. Making the changes manually and restarting slapd works, but my understanding was that changes to cn=config should be made through ldapmodify. Bad practice, it's best to avoid. I also found a tech note at CentOS: https://www.centos.org/docs/5/html/CDS/cli/8.0/Configuration_Command_File_Reference-Core_Server_Configuration_Reference-Accessing_and_Modifying_Server_Configuration.html in section 2.2.2.2 that indicates changes to cn=config will be ignored: If an attribute is added to |cn=config|, the server ignores it. So am I mistaken? Do I need to do something different? I would prefer to manage the config with ldapmodify, but since I don’t change cn=config that often, I can change it manually. Robert Cheers, -- *Abdelhamid MEDDEB* http://www.meddeb.net smime.p7s Description: Signature cryptographique S/MIME
Re: how to check user lock status
Hi, For lock status of the user account you may check his pwdAccountLockedTime attribute pwdMustChange value is overridden by pwdReset, may be the value of this attribute is set to FALSE when you've does your test ? Cheers. Le 16/04/2015 06:38, rockwang a écrit : Hi, all I set policy for user as following # default, policies, abc.com dn: cn=default,ou=policies,dc=abc,dc=com objectClass: top objectClass: device objectClass: pwdPolicy cn: default pwdAttribute: userPassword pwdMaxAge: 7776002 pwdExpireWarning: 432000 pwdInHistory: 3 pwdCheckQuality: 1 pwdMinLength: 8 pwdMaxFailure: 5 pwdLockout: TRUE pwdLockoutDuration: 900 pwdGraceAuthNLimit: 0 pwdFailureCountInterval: 0 pwdMustChange: TRUE pwdAllowUserChange: TRUE pwdSafeModify: FALSE my question is how to check user lock status. Another question is pwdMustChange doesn’t work in linux client when user first login. Rock.wang -- *Abdelhamid MEDDEB* http://www.meddeb.net smime.p7s Description: Signature cryptographique S/MIME
Re: multiples syncrepl from same host and DB
Hi,
I don't think so.
Try instead:
olcSyncrepl: {0}rid=201 provider=ldap://master searchbase=suffixDB filter=(a
filter who return data in both branch1 and 2) ...
Reset the data in slave before trying again
Maybe it would be better
Cheers
Le 15/04/2015 14:00, openldap-technical-requ...@openldap.org a écrit :
hello,
I wanted to synchronize 2 branches of a master DB (slapd-2.4.38). So I
created 2 olcSyncrepl on the slave :
olcSyncrepl: {0}rid=201 provider=ldap://master
searchbase=cn=branch1,suffixDB scope=sub
olcSyncrepl: {1}rid=202 provider=ldap://master
searchbase=cn=branch2,suffixDB scope=sub
Unfortunatly, it doesn't work. A change on branch2 on the master
produces often a CSN too old on the slave.
After investigating, it seems that the pb comes from the fact there is
one contextCSN by DB. So if the sync task on branch1 is the first to
process, it updates the contextCSN and therefore the sync task on
branch2 thinks that change is not newer. Am I right ?
So is there a proper way to achieve what I want ?
--
*Abdelhamid MEDDEB*
http://www.meddeb.net
smime.p7s
Description: Signature cryptographique S/MIME
