Re: OpenLDAP UTF8 values support
On Wed, Mar 21, 2018 at 07:35:34PM +, André Rodier wrote:
> On 21/03/18 17:19, Michael Ströder wrote:
> > That's why I proposed 'intlMailAddr' herein:
> > https://tools.ietf.org/html/draft-stroeder-mailboxrelatedobject-07#section-2
> >
> > Note that this attribute only makes sense in case of non-ASCII local part
> > and for use with SMTPUTF8 extensions. I currently only know of one SMTPUTF8
> > implementation (postfix 3.x).
> I am using postfix 3 as well, with dovecot.
So you can probably use that extension. However, most people cannot.
Therefore if you create mail accounts with non-ASCII characters in the
local part those accounts will not be able to exchange mail with 95%
of the world's population. (unless you install a translating gateway,
but then the address seen outside your system will not be the same as
the one inside and your users will get confused).
This is why the LDAP mail attribute is limited to IA5 (7-bit ASCII) syntax.
None of this prevents having UTF8 characters in the 'comment part', as you
do youself ("André" contains one character that cannot be represented in
IA5). This part is not stored in the LDAP mail attribute, which should
be just LHS@RHS.domain
Andrew
--
-----------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/+44 1628 782565 |
---
Re: LDAP Account expiry
On Thu, Mar 08, 2018 at 05:18:55AM +, Brad Marshall wrote: > As I understand there's no native way to do this, I've written a python script > that loops over and checks the authTimestamp from the lastbind overlay, which > is all good. To lock the account I set the pwdAccountLockTime to the > timestamp, which all works well with the ppolicy overlay in place. > > The problem becomes when we want to unlock the accounts, and give the end > users > a chance to auth so it will clear out the lock. My understanding from reading > the code was that I could set the timestamp for pwdAccountLockTime into the > future, and it should expire the account when it gets to that time. This > gives > the users a grace period in which to authenticate. As you have found, that is not going to work. pwdAccountLockedTime is an operational attribute used by the server to *record* when the password was actually locked. It does not mean 'lock the account at this time'. In OpenLDAP the mere presence of this attribute in an entry locks the password. This is a bit of a fudge in the "standard" (actually a long series of Internet Drafts) or perhaps in OpenLDAP's interpretation of it. Operational attributes are not supposed to be modified directly, yet the standard way to lock an account is to set pwdAccountLockedTime to 0101Z. > Should any of this be working? Am I missing any piece of this puzzle here? > Has anyone got any suggestions on how to solve this problem, either via the > approach I'm trying or any alternative solution? Please let me know if I've > left any useful information out about this. You might get somewhere by artificially expiring the password and giving the account a couple of grace authentications, but this also requires modifying operation attributes and it does not set a time limit. I think you are going to have to create a new attribute to hold the time you want the password to re-lock. You can then either write an overlay to enforce it or (simpler perhaps) extend your python script to check and re-lock accounts that have not logged in before the deadline. This is one of the problems with the existing password policy framework. It mixes password policy with account policy for historical reasons (most of the concepts came from Unix password policy files). As you say above, you want to unlock the *accounts* which is not the same as unlocking the *passwords* because there may be non-password ways of authenticating and you want to block those too. Note also that some features of password policy have "interesting" behaviour when replication is involved. Andrew -- ----------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Using virtual IP and N-way mutlimaster mode
On Wed, Jan 24, 2018 at 09:43:58AM -0800, Quanah Gibson-Mount wrote: > > How about adding a flag to slapd to specify the server ID so that it can > > go the other way through the config, convert ID to FQDN, and drop that > > FQDN from the set of replication sources? > > I'll discuss with Howard, and see. I hate seeing more options added to > slapd, but it may be the only option (no pun intended!) for this scenario. > ;) The cloud was fairly nascent when this was all designed, so this case > wasn't really a consideration at that point in time. If you were to pass in > the server ID, I think you could get rid of the multi-valued serverID bit > entirely, since every server would know who it was already. I think you would still need that. Maybe I have missed something else here, but how does slapd avoid making a syncrepl connection to itself in the replicated-config scenario? I was assuming that it just ignores syncrepl clauses where the provider URL matches its own hostname. If it is done by IP then more thought will be required. The multi-valued attribute is neat in the case of servers with simple IP<->hostname mappings so we would probably want to keep it for that. Andrew -- ----------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Using virtual IP and N-way mutlimaster mode
On Wed, Jan 24, 2018 at 09:27:20AM -0800, Quanah Gibson-Mount wrote: > Please ellaborate on what is risky (or load inducing) about changing the > maxsize. It is entirely my assumption - wrong it would appear, which is good news! I was thinking of this as something like grow/shrink ops on filesystems. > I've had a script for years that has automatically adjusted the > maxsize as necessary based on the size of the DB vs maxsize, etc, via > cn=config. This script has been deployed on servers throughout the world > via my former job @ Zimbra. Changing the maxsize has never been a problem. > > You have 3 basic scenarios: > > #1: You decrease the maxsize to < size of the DB > #2: You set the maxsize = to the size of the DB > #3: You increase the maxsize > size of the DB > > In scenario #1, lmdb refuses to set the maxsize to something less than the > size of the DB. It will make it equal to the size of the DB (Leading to > scenario #2) Is 'size of the DB' the current length of the DB file, or the amount of disk space actually used by it? > In scenario #2, the server will not accept any new growth (write ops will be > rejected). Monitoring should alert you to that, but the system will recover > once you adjust the maxsize to something useful. > > In scenario #3, the maxsize is increased. > > I've not seen any load related issues for such an operation, so it's not > clear to me what you mean by that, either. Just to be clear on this, is it OK to change maxsize in the config file while slapd is down or does this only work with LDAP-based config changes? > The other problem is definitely interesting, and I'm not clear on a good > solution for it. How about adding a flag to slapd to specify the server ID so that it can go the other way through the config, convert ID to FQDN, and drop that FQDN from the set of replication sources? Andrew -- ----------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Using virtual IP and N-way mutlimaster mode
On Wed, Jan 24, 2018 at 06:37:43AM -0800, Quanah Gibson-Mount wrote: > You can change the MDB maxsize at any time, including while slapd is > running. So that scenario at least doesn't compute. ;) I would still rather do such risky / load-inducing changes on one replica at a time. Anyway, running with fully-replicated config makes it even more important to have a good solution to the problem I described. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Using virtual IP and N-way mutlimaster mode
On Tue, Jan 16, 2018 at 10:24:42AM +0400, Jephte Clain wrote:
> all nodes run with -h ldap:// and I have as many olcServerID as defined nodes
> my cn=config is also replicated between all nodes
>
> for example, I have:
> olcServerID: 1 ldap://ldapm3.univ.run/
> olcServerID: 2 ldap://ldapm4.univ.run/
> olcSyncrepl: {0}... rid=0 provider="ldap://ldapm3.univ.run/; ...
> olcSyncrepl: {1}... rid=3 provider="ldap://ldapm4.univ.run/; ...
There is an important variation of this problem when running cloud
machines in services like AWS. The actual machines have IPv4 addresses
in private address space - usually 10.x.x.x - but if you need to access
them from outside their own availability zone (datacentre) you must use
a different (public) IP address. The machines usually have hostnames of
the form ip-10-x-x-x and there is no way to resolve those globally.
So, we might have one server in each of three zones and need to set up
MMR between them:
Zone A:
Server IP: 10.21.0.1
Public IP: 134.82.17.63
Default hostname: ip-10-21-0-1
Zone B:
Server IP: 10.22.0.71
Public IP: 193.17.65.123
Default hostname: ip-10-22-0-71
Zone C:
Server IP: 10.35.0.5
Public IP: 7.45.81.52
Default hostname: ip-10-35-0-5
Not too much of a problem if each server has a separate config, but if
we want replicated configs it gets harder.
The first problem is that the private IP ranges used by the three zones
may overlap. Indeed, there are cases where the three servers could have
identical local IPs (and thus identical default hostnames).
Even without that, we have to cope with the fact that the servers are on
private addresses but have to contact each other using public addresses.
One option would be to set new hostnames on the servers and use those
to key into the appropriate config values. The hostnames would need to be
resolvable to public IP addresses so that the MMR config would work properly.
Does anything check that the hostname actually resolves to an IP address
bound to the server I wonder? Even if OpenLDAP is OK with that, it might
break something else running on the machine.
Another option would be to use the new hostnames in the -h URL list, but as has
already been mentioned this will fail because the server cannot bind to the
public IP.
What is best practice here? I am leaning towards *not* replicating config
because it makes some updates really hard (think changing the max size of
an MDB database without stopping all the servers at the same time). I still
like the idea that the config should be identical on all servers during
normal operation though.
[ Note that I am not considering the OP's virtual IP problem here, as
load-balancing/failover in this environment would be done separately ]
Andrew
--
-------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/+44 1628 782565 |
---
Re: Antw: Re: [Q] amendments to schemes existent
On Fri, Oct 20, 2017 at 01:08:01PM +0300, Zeus Panchenko wrote: > 1. search works with filter: (authorizedService=mail@hh001.umidb) >(and without index it returns empty result) That is odd. Th eindex should only be a performance thing - it should not change the results at all. You need to be very careful about using slapindex whenever you change the list of indexes. > 4. search (unexpectedly) does not work at all with filter: > (authorizedService:caseIgnoreSubstringsMatch:=m...@hh001.umi*) > ># base
Re: Antw: Re: [Q] amendments to schemes existent
On Thu, Oct 19, 2017 at 02:02:55PM +0300, Zeus Panchenko wrote: > is there other way to get originally SUBSTR-less attributes to be > matchable by substring, except hacking the scheme? You could try using the extended search filter syntax: (dhcpOption:caseIgnoreSubstringsMatch:=boot*) See RFC4515 for more details. In practice you will probably want to create a suitable index on the attribute unless the search will also include another attribute that is already indexed and which will cut down the number of results sufficiently. e.g. (&(hostCategory=finance)(dhcpOption:caseIgnoreSubstringsMatch:=boot*)) Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: [Q] amendments to schemes existent
On Tue, Oct 03, 2017 at 11:35:56PM +0300, Zeus Panchenko wrote: > I'm wondering of search possibility lack for some attributes > > my question is: is it correct/good/sane/e.t.c. to patch them this > way? is there other way to get those attributes searchable? You should not change the definitions of standard attributes or objectclasses. That does not stop you from setting up an index for the attribute though, and most LDAP servers will then allow you to search for it even if the published schema does not allow for the possibility. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
LDAPCon 2017 programme now online
The programme for the 2017 LDAP Conference has just been published: https://ldapcon.org/2017/conference-program/ It's looking good, so get your booking in quickly to get early-bird tickets and start thinking about where you want to stay in Brussels! The conference runs 19th and 20th October 2017. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: ppolicy issues
On Tue, Aug 08, 2017 at 07:46:02PM +0200, Michael Ströder wrote: > Yes, slapo-ppolicy config can be different per database. > Also consider setting password-hash / password-crypt-salt-format per database. Be aware that you must put ppolicy entries (including default entries) in the same database as the entries that they will govern. Thus you need at least one policy entry in each backend DB. See ITS#7262 for details: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=7262;selectid=7262 Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Openldap Configuration issues
Please keep the discussion on-list so that others can find it if they have similar problems. On Tue, Aug 08, 2017 at 12:44:25PM +0200, R H wrote: > Subject: Re: Openldap Configuration issues > > No point in changing stuff without knowing what is going on. > > Add this to your config and restart slapd: > > loglevel stats,stats2 > after setting loglevel to stats, stats2 > > Aug 8 05:40:18 docker slapd[2990]: daemon: read active on 14 > Aug 8 05:40:18 docker slapd[2990]: daemon: epoll: listen=9 active_threads=0 > tvp=zero > Aug 8 05:40:18 docker slapd[2990]: daemon: epoll: listen=10 active_threads=0 > tvp=zero No - something has set a different log level. You are seeing a lot of connection-management and debug stuff rather than the query and response summaries that you need. You might do better to stop the server and run it manually. Something like this: /usr/sbin/slapd -d stats,stats2 -h ldap:/// -g openldap -u openldap What I am expecting to see looks more like this (from a Cyrus mailbox server using LDAP via saslauthd): Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=103 BIND anonymous mech=implicit ssf=0 Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=103 BIND dn="cn=saslauthd,dc=ldap,dc=example,dc=com" method=128 Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=103 BIND dn="cn=saslauthd,dc=ldap,dc=example,dc=com" mech=SIMPLE ssf=0 Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=103 RESULT tag=97 err=0 text= That shows saslauthd connecting to LDAP and authenticating correctly. Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=104 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(uid=myusername)" Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=104 SRCH attr=dn That is the search to find the user account. Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=104 ENTRY dn="uniqueIdentifier=1405431085.7365.0,associatedDomain=example.co.uk,ou=domains,dc=example,dc=com" Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=104 SEARCH RESULT tag=101 err=0 nentries=1 text= That shows the search result: the user entry is "uniqueIdentifier=1405431085.7365.0,associatedDomain=example.co.uk,ou=domains,dc=example,dc=com" Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=105 BIND anonymous mech=implicit ssf=0 Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=105 BIND dn="uniqueIdentifier=1405431085.7365.0,associatedDomain=example.co.uk,ou=domains,dc=example,dc=com" method=128 Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=105 BIND dn="uniqueIdentifier=1405431085.7365.0,associatedDomain=example.co.uk,ou=domains,dc=example,dc=com" mech=SIMPLE ssf=0 Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=105 RESULT tag=97 err=0 text= Finally the password is checked by binding to LDAP using the account DN and password as credentials. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Openldap Configuration issues
On Sun, Aug 06, 2017 at 05:54:56PM +0200, R H wrote: > which is great, this is exactly the way it should look like, however I've > noticed, that cn=admin,o=testcompany.com entry doesn't exists, while it > did > using the default config after i've installed openldap. I assume that you cleared out the database at some point (which you should do, to get rid of example entries from the distro). Thus, cn=admin,o=testcompany.com will not exist unless you explicitly create it - and nor will o=testcompany.com which you need to create first. > 6. In Redmine, I've configured and tested the ldap authentication. It is > working correctly (it can both connect to my ldap and If i wish to add a > new user and choose the before configured ldap authentication for it, i > can > even choose from the entries that are in my ldap, which is also great) > > 7. However (this is where my problem is) when i try to log into Redmine with > a > user that i've just created (with ldap authentication) i always get > Invalid > credentials error (while it works like a charm when i login with any other > account, created with Simple Authentication) > > These events led me to believe that the error is in the LDAP configuration. Maybe, maybe not... > After a few more hours/days of fooling around with the ACLs and > dpkg-reconfigure slapd (and even purging-reinstalling slapd and ldap-utils) i No point in changing stuff without knowing what is going on. Add this to your config and restart slapd: loglevel stats,stats2 Find where the log stream goes to - probably /var/log/daemon.log or similar. Look at the LDAP operations and results when you try to login on your app. This will tell you what the app is actually doing. Andrew -- ----------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: [Q] "selective" ACL
[ This is a very old thread you are resurrecting! ] On Fri, Sep 09, 2016 at 01:51:47PM +0300, Zeus Panchenko wrote: > I have two posixGroup groups > > cn=admins,ou=group,dc=foo > cn=coadmins,ou=group,dc=foo > > my users resides in ou=People,dc=foo > > so, in subtree ou=People,dc=foo I need to allow anything to admins (and > it is not difficult of course) > > for example this works for me: > > access to dn.subtree="ou=People,dc=foo" > by set="[cn=admin,ou=group,dc=foo]/memberUid & user/uid" manage > by self write > by users read > by * break > > but in addition I need to allow my coadmins to do the same things except > manipulations upon the objects which belong to admins ( > ...anyobject,uid=adminuser,ou=People,dc=foo ) > > so, the question is: how? (if it is possible at all) :( It depends partly on why the ACI ends with 'by * break'. What other rules could be applied in that case? In the simple case where 'by * none' would have the same effect, you could just put another ACI ahead of the one above so it comes out like this: access to by self write by users read by * none access to dn.subtree="ou=People,dc=foo" by set="[cn=admin,ou=group,dc=foo]/memberUid & user/uid" manage by self write by users read by * none The problem is to write the ''. That would probably be easier if you were not defining admin users by their UID in a Posix group. Ideally there would be an attribute visible in each entry that defines admin status, as then you could just key on that. If your admin group is defined as a standard DN-based groupOfNames then you could use the memberof overlay to reflect membership into an attribute of the user entry. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: syncrepl fails after upgrade to openldap 2.4.45
On Mon, Jun 26, 2017 at 11:09:43AM -0700, Quanah Gibson-Mount wrote: > Now you're switching topics. Your original mail did not include > cert authentication, it used simple binds: > > syncrepl rid=000 > provider=ldaps://ldap.dannatu.ch:636 > type=refreshAndPersist > retry="5 5 300 +" > searchbase="dc=dannatu,dc=ch" > attrs="*,+" > scope=sub > bindmethod=simple > binddn="cn=Manager,dc=dannatu,dc=ch" > credentials=** > > > Either way, cert authentication AND TLS encrypted syncrepl both work > for me with OpenSSL 1.0.2l and OpenLDAP 2.4.45 just fine, so I would > have to again guess issues with proper TLS configuration. It seems that the CA cert was never referenced in the syncrepl clause, so it would have dropped back to whatever TLS config was in the LDAP *client* config file (probably /etc/ldap/ldap.conf). I seem to remember a change in behaviour of OpenSSL libs a while ago where I was bitten by something similar. Maybe Juergen's earlier setup used ldap.conf and the new one is ignoring it? Andrew -- ------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: [Q] can I replicate several branches to the same slave from one master?
On Thu, Jun 29, 2017 at 03:47:07PM +0100, Andrew Findlay wrote: > I suspect part of the trouble is that you have two syncrepl clauses using the > same search base on the same master. The timestamps are likely to be stored > in the same place, causing a clash. > > One definite error is that all three clauses are labelled 'rid=123'. They > should > all have different numbers. As it happens, Quanah has just replied to a question with a very similar issue. See message below, and also the ITS: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8100;selectid=8100 ... so you should also make at least one change to data on the master node so that the syncrepl process has something to do. Andrew On Tue, Jun 27, 2017 at 01:55:34PM -0700, Quanah Gibson-Mount wrote: > Date: Tue, 27 Jun 2017 13:55:34 -0700 > From: Quanah Gibson-Mount <qua...@symas.com> > To: btb <b...@bitrate.net>, openldap-technical@openldap.org > Subject: Re: mmr pair stops replicating: "consumer state is newer than > provider" > Sender: openldap-technical <openldap-technical-boun...@openldap.org> > > --On Tuesday, June 27, 2017 5:35 PM -0400 btb <b...@bitrate.net> wrote: > > >On 6/27/17 10:27 AM, Quanah Gibson-Mount wrote: > >>--On Tuesday, June 27, 2017 10:37 AM -0400 btb <b...@bitrate.net> wrote: > >>>i'm using 2.4.44 on freebsd, built from ports. i can provide any config > >>>details etc - i just didn't want to inundate the post with guesses on > >>>detail that might not be relevant. > >> > >>What is your accesslog purge setting? Do you have long periods of time > >>with no write activity? > > > >there are some extended periods of time with no write activity, yes. > > That's one form of a known issue then with using accesslog > (ITS#8100). I've made a suggestion on how it could be fixed, and > Howard agreed that would be the correct solution. Just need the > fix. :) > > In the meantime, you can set up a cronjob that does a modify once a > day on some object that doesn't really do anything, like if you had: > > dn: cn=someobject,dc... > objectClass: ... > cn: someobject > description: blah > > you could have a job that does: > dn: cn=someobject,dc... > changetype: modify > replace: description > description: blah > > So it in effect does nothing, but it keeps an active change in the > accesslog alive. > > Basically what happens with the accesslog empty is that it'll end up > generating its own new contextCSN that differs for that server than > the one stored in the rootDB, and will be /newer/ than it as well, > which is why you get that message. You can also fix the problem > simply by doing a modify on each master, and it'll reset the > contextCSNs and things will flow (i.e., no need to do a dump/reload, > etc). > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: [Q] can I replicate several branches to the same slave from one master?
On Tue, Jun 27, 2017 at 01:04:38AM -2100, Zeus Panchenko wrote: > Subject: [Q] can I replicate several branches to the same slave from one > master? > on master I see: consumer state is newer than provider > on slave: LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform > > so ... what is wrong here? I suspect part of the trouble is that you have two syncrepl clauses using the same search base on the same master. The timestamps are likely to be stored in the same place, causing a clash. One definite error is that all three clauses are labelled 'rid=123'. They should all have different numbers. Try fixing the RIDs - use small numbers, all different. The exact values are not important. Also try commenting out the second syncrepl clause until you have the others working properly. You should be able to merge the first and second clauses as they share a search-base. You may also need to put ACLs on the accesslog database. Andrew > - ---[ master configuration quotation start ]--- > ... > access to dn.children="dc=example" >by dn.exact="uid=replABC,ou=repl,dc=example" read >by * break > > # syncprov specific indexing > index entryCSN eq > index entryUUID eq > > overlay syncprov > syncprov-checkpoint 50 10 > syncprov-sessionlog 100 > > overlay accesslog > logdb cn=example-accesslog > logops writes > logold (objectclass=*) > index default eq > > ### Accesslog DB > databasemdb > maxsize 1073741824 > suffix cn=example-accesslog > rootdn "cn=root,cn=example-accesslog" > rootpw *** > directory "/var/db/openldap-data/example-accesslog" > > index default eq > index entryCSN,objectClass,reqEnd,reqResult,reqStart > > overlay syncprov > syncprov-nopresent TRUE > syncprov-reloadhint TRUE > ... > - ---[ master configuration quotation end ]--- > > > > - ---[ slave configuration quotation start ] > syncrepl rid=123 > provider=ldap://master.example:389 > starttls=critical > searchbase="dc=example" > bindmethod=simple > binddn="uid=replABC,ou=repl,dc=example" > credentials="***" > filter="(|(&(objectClass=authorizedServiceObject)(objectClass=mailutilsAccount)(authorizedService=m...@foo.bar)))" > attrs="cn,entry,entryCSN,entryUUID,o,uid,uidNumber,gidNumber,gecos,homeDirectory,loginShell,userPassword,creatorsName,createTimestamp,modifiersName,modifyTimestamp,mail,rfc822MailMember,sn,authorizedService,mu-mailBox" > tls_cacert=/usr/local/etc/openldap/ssl/ca.crt > tls_cert=/usr/local/etc/openldap/ssl/ABC.crt > tls_key=/usr/local/etc/openldap/ssl/ABC.key > tls_reqcert=try > type=refreshAndPersist > retry="60 +" > logbase="cn=example-accesslog" > logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" > syncdata=accesslog > > syncrepl rid=123 > provider=ldap://master.example:389 > starttls=critical > searchbase="dc=example" > bindmethod=simple > binddn="uid=replABC,ou=repl,dc=example" > credentials="***" > filter="(&(objectClass=authorizedServiceObject)(authorizedService=x...@foo.bar))" > tls_cacert=/usr/local/etc/openldap/ssl/ca.crt > tls_cert=/usr/local/etc/openldap/ssl/ABC.crt > tls_key=/usr/local/etc/openldap/ssl/ABC.key > tls_reqcert=try > type=refreshAndPersist > retry="60 +" > logbase="cn=example-accesslog" > logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" > syncdata=accesslog > > syncrepl rid=123 > provider=ldap://master.example:389 > starttls=critical > searchbase="ou=ABC,ou=Sendmail,dc=example" > bindmethod=simple > binddn="uid=replABC,ou=repl,dc=example" > credentials="***" > tls_cacert=/usr/local/etc/openldap/ssl/ca.crt > tls_cert=/usr/local/etc/openldap/ssl/ABC.crt > tls_key=/usr/local/etc/openldap/ssl/ABC.key > tls_reqcert=try > type=refreshAndPersist > retry="60 +" > logbase="cn=example-accesslog" > logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" > syncdata=accesslog -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Permission issue for normal user with ldap_add
On Thu, Jan 19, 2017 at 10:23:22AM +0100, Dieter Klünter wrote: > man slapd.access(5) See also some examples in the Admin Guide: http://www.openldap.org/doc/admin24/access-control.html#Access%20Control%20Examples More examples here: https://www.skills-1st.co.uk/papers/ldap-acls-jan-2009/ For any non-trivial policy I would suggest building a test-suite before trying to write the ACLs. OpenLDAP has one of the most predictable ACL mechanisms in the industry but it can still be hard to cover all the edge-cases correctly. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: LDAP search rule to find group owners
On Mon, Jan 16, 2017 at 03:21:41PM +, Philip Colmer wrote: > to dn.sub="ou=groups,dc=example,dc=com" by dnattr="owner" write by set="this/ > owner/member & user" write by users none by * none > Is there a way of performing an LDAP search that does the equivalent of the > ACL > (or something like it) to tell me which groups can be written to for a given > DN? I don't think you will be able to do that in a single LDAP operation on a standard server. The most efficient way is probably: Search for all groups that the user is a member of, returning just the DN Search for all groups where any of those DNs are found in the owner attribute Beware though, that if some users are members of very large numbers of groups then the search assertion could be very large... If you have the memberof overlay then you may be able to simplify the process by having it maintain an 'ownerOf' attribute in the group entries. Then you could get what you want in a single search: Match: (&(objectclass=groupOfNames)(member=)) Return: ownerOf attribute This may return multiple entries. You just need to gather up all the ownerOf values. To be really cute you could add the dynlist overlay to do this for you... Andrew -- ----------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Slapd.conf for doing stress
On Thu, Jan 12, 2017 at 02:39:12PM +0530, PRATIK SINGAL wrote: > Am new to openldap and need to perform stress on openldap2.4. > Can any one please provide me with some usefull link / optimized conf file for > stress. Optimisations will depend on the data you will use and on the operations being done. In particular, the indexing setup can have a big effect on performance and the 'optimum' configuration depends on the mix of searches and updates. > we are using Berkley DB. That is not optimum :-) Install 2.4.44 and use mdb for best results... Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Searches with dereferncing causing high CPU load.
On Tue, Nov 17, 2015 at 06:02:36PM +, Howard Chu wrote: > slapindex on back-mdb is faster than slapadd. But, for the problem > being discussed here, slapindex is inadequate; you need a full > reload with slapadd. Useful to know, thanks. What about the root cause - is it likely that 64k aliases would trigger a problem, or is something else going on here? Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Searches with dereferncing causing high CPU load.
On Tue, Nov 17, 2015 at 11:11:04AM +, Mark Cairney wrote: > Just as an update- we've managed to restore service. It turns out that > we had went over the value of 65,535 (66,291) aliases which we think was > the root cause of this behaviour suddenly starting. It's a significant number certainly... > Although it relates to MDB this ITS sounded very similar: > http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8146;page=10 > > We started deleting as many aliases as we could but performance only > improved slightly. What appears to have fixed it was doing a slapcat of > the "pruned" data and re-loading it into the database via slapadd. > Having done this searches with deref set to always are now performing as > they were before. If this happens again, you could try stopping the server and running slapindex rather than reloading everything. > Ultimately we've been wanting to move away from both a) hdb and b) > aliases for a while but one of our user bases runs a web application > that requires them as it doesn't support either groups or modifying it's > search filter. Given this incident there might be a push for them to > re-evaluate this approach. That does sound like a problematic app. There may be other ways of solving the problem if you have to keep it though. I would tend to look at having a separate instance of slapd to service it, and it might then be possible to use mapping overlays to build a view of your data that it can cope with. Does the app need to modify LDAP data or is it read-only? Andrew -- ------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Searches with dereferncing causing high CPU load.
On Mon, Nov 16, 2015 at 03:13:11PM +, Mark Cairney wrote: > We're having severe performance issues for any query with alias > dereferencing set to "always". > > Any query with this causes the CPU to spin up to 100% and if we have a > number of these concurrently the machine will become unresponsive. I hit something similar a while ago using mdb: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8146 > We're using OpenLDAP 2.4.42 with the old hdb backend. > > We do have a large number of aliases (~63,000). Could this be the cause? It would be worth checking that you have indexed the objectclass attribute. I prefer to avoid aliases... Andrew -- ------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: ldiftopasswd: Can it be done with SSHA hashes?
On Wed, Nov 04, 2015 at 04:45:28PM +, Chuck Peters wrote: > Can I convert the ldif's userPassword:: "salted hash, aka SSHA" to "hash > type$salt$hash" format of shadow passwords? Not usefully: there is no support for single-round SSHA1 in most Unix-like crypt(3) libraries. > Or do I need to force those users with SSHA hashed passwords to change their > password? Yes > Most of the users passwords are in crypt format. I found a perl one liner to > base64 decode those passwords hashes. (1) By 'crypt format' do you mean the old Unix 13-char DES-based hash, or one of the newer ones? At present you should really only be using the newer multi-round hashes, with this order of preference: $2y$ or $2a$Bcrypt $6$ Multi-round SHA512 $5$ Multi-round SHA256 $1$ Multi-round MD5 > I'm attempting to create shadow passwd files with an old Debian 6.0.10 > (squeeze) LDAP installation and Debian's slapd package (2.4.23-7.3+deb6u2 > squeeze-lts patched oldoldstable) includes a perl script ldiftopasswd, which > I thought came from upstream, but it's not included in the most recent source > of openldap. If my reading of the perl is correct, it was meant for earlier > iterations of shadow passwords that did not include hash format or salt. I'm > not having any success using the script this far. > > > 1. http://www.perlmonks.org/bare/?node_id=963814 > alias ldapdecode="perl -MMIME::Base64 -n -00 -e 's/\n //g;s/(?<=:: > )(\S+)/decode_base64(\$1)/eg;print'" and just do ldapsearch | ldapdecode That script simply converts the Base64 encoded fields of an LDIF file into their native (binary) format. Beware of old distros as they may not support all of the hash formats. Why do you need a passwd/shadow file in the first place? Surely it is much better to set your systems up to validate logins against LDAP directly. That way the only thing that needs to care about hash formats is the LDAP server process. Andrew -- ------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Allowing users to update their passwords
On Tue, Oct 13, 2015 at 09:02:01AM +0200, Dieter Klünter wrote:
> Am Mon, 12 Oct 2015 16:13:18 -0500
> schrieb Kartik Vashishta <kartik.u...@gmail.com>:
>
> > Team,
> >
> > I am not anything but new to ldap. I have however successfully
> > installed and configured Openldap on CentOS7. Online material was a
> > BIG help.
> >
> > I am trying to figure out how to allow users to change their own
> > passwords.
> >
> > Googling pointed me out to this:
> > access to attrs=userPassword
> > by self write
> > by anonymous auth
> > by users none
> >
> > access to * by * read
> >
> > But where and how does this get input into the ldap db. There is no
> > more a slapd.conf.
>
> slapd-config(5)
Also
http://www.openldap.org/doc/admin24/access-control.html#Access%20Control%20via%20Dynamic%20Configuration
I would suggest changing the access list:
olcAccess: to attrs=userPassword
by self =wx
by anonymous auth
by * none
olcAccess: to * by * read
The important change is the 'self' access. If you use 'write' then you are also
granting read access, so someone who gets control of an authenticated session
would be able to read the user's password. By using =w or =wx you allow
passwords to be changed and to be used in authentication, but you prevent them
being read.
You will need to search your config to find the appropriate entry to add the
above values to. It will be something like olcDatabase=mdb,cn=config
You should also configure a strong hash function for passwords, and ideally you
should install a password policy overlay to enforce password hashing.
The choice of hash function depends on the libraries available in your
operating system. SSHA is always available but is very weak in the face of a
password cracker. The Linux/FreeBSD/OpenBSD '$1$' '$6$' and '$2a$' hashes are
very much stronger. Config looks like this:
olcPasswordHash: {CRYPT}
olcPasswordCryptSaltFormat: "$6$%.12s"
It should be added to the olcDatabase=frontend,cn=config entry.
Andrew
--
---
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/+44 1628 782565 |
---
Re: SSL based LDAP client verification
On Wed, Oct 07, 2015 at 02:13:38AM +0500, Aneela Saleem wrote: > I have followed this link to generate self-signed certificates. I have > successfully performed server side validation. I assume that means that you have made an SSL or TLS connection to the server and done an LDAP operation, so this operation should succeed: ldapwhoami -x -H ldap://my.server.com/ -ZZ If it does not, you may need to specify the TLS_CACERT location in /etc/openldap/ldap.conf or temporarily provide the cert location in the environment: LDAPTLS_CACERT=/path/to/ca.crt ldapwhoami -x -H ldap://my.server.com/ -ZZ Don't start trying to use any other clients until you have the command-line ones working properly. > What if i want to access LDAPS:/ > / from other client. I have copied servercrt.pem and serverkey.pem file on > client machine, also added servercrt.pem file to client trust store. I'm using NO! Don't ever give clients the secret key. Assuming you followed http://www.openldap.org/faq/data/cache/185.html fully you created two certificates: a master CA cert and a server-specific cert. You can use the CA cert to create as many server certs as you like, and client machines only need a copy of the CA cert to verify trust. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: New User unable to authenticate on new client
On Mon, Oct 05, 2015 at 09:56:25PM +, Varadi, Louis - 0442 - MITLL wrote: > I have added a user but cannot authenticate. > This user fails > > [root@ldapserver]# ldapwhoami -x -D cn=lou,dc=group1,dc=ldap -W > > Enter LDAP Password: > > ldap_bind: Invalid credentials (49) No surprise there, as your later search shows the user has a different DN: > # lou, Users, group.ldap > dn: uid=lou,ou=Users,dc=group1,dc=ldap > uid: lou > mail: louxxx > sn: > pwdAttribute: xxx > telephoneNumber: xx > roomNumber: > uidNumber: > gidNumber: x > employeeNumber: x > cn: Louis x > loginShell: /bin/bash > gecos: Lou > homeDirectory: /home/ > objectClass: inetOrgPerson > objectClass: posixAccount > objectClass: top > objectClass: pwdPolicy > objectClass: shadowAccount > userPassword:: xxx > [root@ldapserver man1]# su - lou > > su: user lou does not exis > 5612ebc3 conn=1053 fd=12 ACCEPT from IP=192.168.0.101:59310 (IP= > 192.168.0.101:389) > > 5612ebc3 conn=1053 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" > > 5612ebc3 conn=1053 op=0 SRCH attr=* altServer namingContexts supportedControl > supportedExtension supportedFeatures supportedLDAPVersion > supportedSASLMechanisms domainControllerFunctionality defaultNamingContext > lastUSN highestCommittedUSN This session is anonymous (no BIND operation). > 5612ebc3 conn=1053 op=0 SEARCH RESULT tag=101 err=0 nentries=0 text= > > 5612ebc3 conn=1053 op=1 SRCH base="dc=group1,dc=ldap" scope=2 deref=0 filter=" > (&(uid=lou)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0" > > 5612ebc3 conn=1053 op=1 SRCH attr=objectClass uid userPassword uidNumber > gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp > modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning > shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration > pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock > host loginDisabled loginExpirationTime loginAllowedTimeMap sshPublicKey > > 5612ebc3 conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0 text= err=50 If you look that up you find: insufficientAccessRights (50) Indicates that the client does not have sufficient access rights to perform the operation. So the anon user does not have the right to do a search from the base "dc=group1,dc=ldap" (this says nothing about the right to read the uid=lou entry). You have an ACL problem. I suggest removing all ACLs and starting with this: access to attrs="userPassword" by self =w by * auth access to * by * read Once you have the basic service working you can start thinking about ACLs. You may then want to define an account for your Linux client machines to use when accessing LDAP so that you don't have to give anon access to your data. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: uniqueness unique_uri specification help
On Fri, Sep 11, 2015 at 05:26:35PM +, Peter Heinemann wrote: > Working with an ldap implementation that builds the dit from scratch daily > using extracts from an RDBMS. > The nature of the source data/tables and the code that creates the extracts > builds an ldif (imported via slapadd) that has some multi-value attributes, > specifically cn, sn, and givenName because the RDBMS does no case checking. > > Stanzas like this can occur in the ldif: > > dn: uid=aperson,ou=people,dc=school,dc=edu > > cn: Andrew Person > cn: ANDREW PERSON > sn: Person > sn: PERSON > givenName: Andrew > givenName: ANDREW > > and slapadd will happily write them all, but ldapmodify etc. can (and do) > return errors when encountering these entries. You should only use slapadd with correctly-formed LDAP entries. The example given here is not correctly formed because all the attributes you show have case-ignore syntax and the multiple values differ only in case. > What I'd like to do is use ldapadd under the uniqueness overlay instead of > slapadd. But I'm unsure of the specific syntax for the unique_uri > specification so that that cn, sn, and givenName attributes are unique > under/in > each DN. > Most of the examples I've found are how to enforce uniqueness over an entire > branch. Still reading the specifics about uri specification but would > appreciate any assistance. The uniqueness overlay will not do what you want. It is for enforcing uniqueness across multiple entries. If you use ldapadd rather than slapadd then you will not be able to load bad entries such as the one above. However, this is probably still not what you want as it will throw an error rather than removing the unnecessary extra values! I think the best approach would be for your build process to check each attribute before writing the LDIF file. Where: lowercase(next value) matches lowercase(any existing value) then it should either ignore the new value or should overwrite the clashing value in the attribute (e.g. if the new one is mixed case and the existing one is all upper case). It would still be wise to load the data through LDAP rather than using slapadd, but the process will be much slower. How many entries do you have? Do you run multiple LDAP servers? Andrew -- ----------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: OpenLDAP error - ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
On Fri, Sep 11, 2015 at 03:07:00PM +0200, Clément OUDOT wrote: > Le 11/09/2015 14:54, Varadi, Louis - 0442 - MITLL a écrit : > slapd: [INFO] Listening to services ldap://*:389 ldaps://*:636 > I ran the command tail –f /var/log/openldap.log > Maybe you are using the ldapsearch command from the distro, which may not work > with LTB package. Try /usr/local/openldap/bin/ldapsearch > > Check also your selinux configuration and your iptables. It is worth trying ldapsearch with the debug option to see where it is trying to connect: ldapsearch -x -d 1 The first few lines of output should look something like this: ldap_create ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP ldap.example.com:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 2001:479:1f45:20::201 389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request Using the same command on a machine that does not have an LDAP server configured looks like this: ldap_create ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying ::1 389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect errno: 111 ldap_close_socket: 3 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 127.0.0.1:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect errno: 111 ldap_close_socket: 3 ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) Look particularly at the ldap_connect_to_host: lines. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
LDAPCon 2015 booking now open
LDAPCon 2015, the fifth International Conference on LDAP, Directory Services and Identity Management will be held in the UK at the University of Edinburgh School of Informatics Forum. Tutorials: 11th November 2015 Conference: 12th and 13th November 2015 We have 22 peer-reviewed papers. Topics include service design, LDAP schema, protocol enhancements, server technology and client programming. There will be a poster display area for updates on the very latest work-in-progress, and a social event in a spectacular city-centre venue for networking with other LDAP professionals. http://ldapcon.org/2015/ Several of the regular contributors to this list will be speaking. Booking is now open and early-bird prices are available until the end of September. For full details see the booking page: http://ldapcon.org/2015/?page_id=112 Book now to get the early-bird price! There are opportunities for commercial sponsorship that will be of interest to companies working in related areas. See http://ldapcon.org/2015/?page_id=101 for details. Andrew Findlay Conference Chairman Thanks to our sponsors for their support. Our first Platinum sponsor: Symas http://symas.com/ -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: ldapmodrdn accented characters with windows client
On Tue, Sep 08, 2015 at 04:06:42PM +0200, LAROCHETTE Philippe wrote: > In fact, it's working fine if i replace the "é" character with this sequence > "\c3\a9" OK - so it works if you feed it UTF-8. This is expected, as LDAP expects every text string to use the UTF-8 encoding and the standard version of the command-line tools does not do any character-set conversion. > 1 - I precise that i use a normal command-line charset like chcp 1250 or chcp > 850 with the Lucidia Font in the windows console that show correctly the > accented characters in the windows command Can you change the working locale of the system to use UTF-8 ? If you are really using Windows XP this may be hard, but it is really time to get rid of that obsolete OS anyway. Can you move the client application to a Linux platform? Most modern distros default to UTF-8 which makes this easy. > 2 - When i use ldapadd or ldapmodifiy, i have no problem with the accentes > characters... but for this command i copy the .exe binaries from the OID 11g > of oracle windows client... but in this product for windows there is not à > ldapmodrdn.exe program... In those cases the accents may be in data files in UTF-8 of course. It also sounds as if you are getting ldapmodify from a different set of binaries so maybe one set has charset conversion and the other does not. If you really have to keep the XP system you might be able to build a workaround using something like iconv to process the command-line args and input files: iconv --from-code=CP1250 --to-code=UTF-8 /path/to/inputfile Andrew -- ------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: load balancer
On Fri, Aug 28, 2015 at 02:38:33PM +0800, Eileen(=^ω^=) wrote: >I have two LDAP servers using mirrormode. I want to run a FREE service to > achieve load balancer for these servers. >Due to i can't find any load balancer information in OpenLDAP-Admin-Guide, > so my question is which kind of service do you advice for load balancer, or > which kind service openldap supported? Depending on exactly what you want to achieve, you may not need to run a separate service at all. Much LDAP client software allows you to specify multiple servers, which will be tried in rotation until one answers. This gives protection against unreachable servers. Another option is to put several 'A' or '' records in the DNS entry for your LDAP service (use a service-specific name like ldap.example.org rather than the name of the server). Most DNS servers will change the order of records in each reply (round-robin DNS) so your clients are likely to spread their load across all servers and will fall back to a different server if the first attempt does not connect. The solutions above involve TCP timeouts if servers go down, and this may be too slow for you. One way to get around that is to use a service-specific IP address which is shared by two or more servers. Each server monitors the other and will take over the service address if necessary. Note that this does not give you load balancing between the servers: it is a hot-standby system. If you do not trust the client software to work properly with multiple server addresses then you could use OpenLDAP with the LDAP back-end or the META back-end. Both allow you to specify multiple servers and will handle fallback even if clients don't. This configuration has a very low resource requirement so you can run an instance of it on every client machine if you need to. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: disable simple paged results control support?!
On Thu, Aug 27, 2015 at 01:46:53PM +0300, Igor Shmukler wrote: > Is it possible to disable OpenLDAP server-side support of simple paged > results control, so the OpenLDAP server would respond that this > control is unavailable? > > I don't have an LDAP proxy, nor ODSEE configured. OpenLDAP saved me > many times, in past. Can OpenLDAP be configured to do what I need, so > I could test my fallback code in the client using an OpenLDAP server? Have a look at the RETCODE overlay: slapo-retcode(5) - this should allow you to return whatever error codes you like to your client during testing. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Replication speed and data sizing (mdb)
On Mon, Aug 10, 2015 at 05:19:22PM -0700, Brian Wright wrote: We're trying to solve the problem of how to recover/replace a failed node in a system containing a very large number of records and bring it back into the cluster as quickly as possible. We're also trying to resolve how to ensure that replication works consistently on restart. In terms of recovering a failed node, the very fastest method is to use a database backup made with mdb_copy. The output from that command is a file that can be used directly as an MDB database so all you have to do is put it in place and restart slapd. Even if the backup is a day or two old, the replication process should bring in the more recent changes from another server. If your servers have identical software, you can even take a backup from one server and install it on another one. That gives you a quick way of copying in very fresh data. Note that mdb_copy is not installed by default. For safety you must use a binary built from the same OpenLDAP distribution as your slapd. You will find the source for the MDB tools in openldap-2.4.*/libraries/liblmdb There are some caveats with mdb_copy. In particular it can cause database bloat if run on a server that has a heavy write load at the time. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Adding Members to Groups
On Fri, Aug 07, 2015 at 01:46:42AM +0500, Aneela Saleem wrote: So which objectClass best suits for this situation? If you want to have groups that are easy to adminster and are capable of being empty then you should consider groupOfEntries. A quick scan through the Apache Ranger docs suggests that you can configure the group class and group search so this may well work. You will need to add the groupOfEntries class to your LDAP server schema as it is not likely to be there by default. On Fri, Aug 7, 2015 at 1:42 AM, Michael Ströder mich...@stroeder.com wrote: Or rather ietf-ldapext *WG* should make progress with draft-findlay-ldap-groupofentries... ;-) You can use the class defined in that draft even if IETF don't officially endorse it. Copy attached to this message. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | --- Network Working Group A. Findlay Internet-DraftSkills 1st Ltd Expires: March 16, 2008 September 13, 2007 The LDAP groupOfEntries object class draft-findlay-ldap-groupofentries-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 16, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This memo describes the LDAP groupOfEntries object class which is a replacement for the existing groupOfNames class. The new class permits the creation of empty groups. If approved as a Standards Track document, this document will update RFC4519 [2] Document Intent This document is intended to be, after appropriate review and revision, submitted to the RFC Editor as a Standards Track document. Distribution of this memo is unlimited. Technical discussion of this document will take place on the IETF LDAP Extensions mailing list ldap...@ietf.org. Please send editorial comments directly to the author andrew.find...@skills-1st.co.uk 1. Introduction A groupOfNames object class has existed since the earliest X.521 [1] standard. It has an identical definition in LDAP (RFC4519 [2]). The class is used to define entries holding DN-valued member attributes, each value pointing to an entry that represents a single member of the group being described, or to another entry of type groupOfNames. groupOfNames is a structural object class, so it is often the only class used in the definition of group objects. Experience has shown that the definition of groupOfNames causes difficulties in practice. In particular, the fact that 'member' is a mandatory attribute means that it is not possible to create an empty group or to delete the last member from a group. This leads to artificial tricks such as making every group a member of itself, or adding a dummy member to every group when it is created. These tricks in turn make the management of groups more complex and prone to error. Groups are commonly used to control access to resources, so management errors can lead to security risks. There does not appear to be any good reason for the 'member' attribute to be mandatory. This memo describes a new object class called groupOfEntries that is equivalent to groupOfNames in all other respects but which makes 'member' an optional attribute. 2. The existing groupOfNames object class RFC4519 [2] contains this definition: The 'groupOfNames' object class is the basis of an entry that represents a set of named objects including information related to the purpose or maintenance of the set. (Source: X.521 [1]) ( 2.5.6.9 NAME
A new open-source TLS implementation
Amazon have just announced a completely new implementation of TLS. By avoiding all the history and ignoring features that they don't need the code has been cut by a factor of 10 when compared with the equivalent part of OpenSSL. OpenSSL or some other crypto library is still needed, but this is surely worth a look for future use with LDAP: http://blogs.aws.amazon.com/security/post/TxCKZM94ST1S6Y/Introducing-s2n-a-New-Open-Source-TLS-Implementation https://github.com/awslabs/s2n/blob/master/README.md Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: group email addresses
On Thu, Jun 18, 2015 at 08:13:48AM -0400, brendan kearney wrote: I am using postfix. is there a benefit to the group based expansion piece you speak of? Postfix is already tied to my ldap instances for user aliases, etc. It would allow you to use the LDAP groups to define the members of the mailing list as well as the address of the list. The Postfix LDAP README has some ideas about how you might set this up: http://www.postfix.org/LDAP_README.html#example_group Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: group email addresses
On Sat, Jun 20, 2015 at 10:11:38AM -0400, Brendan Kearney wrote: I am just wondering which OID (and schema) is the least unofficial or the most official one to use. It does not really matter. All you need from an OID in an LDAP system is that it does not clash with anything else. The designers of those schema have presumably allocated OIDs from a space that they control so any of them should be OK. Attribute names are more important, and certainly must not clash with anything else that you are likely to use so make sure they have been chosen sensibly. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
LDAPCon 2015 submission deadline approaching
LDAPCon 2015 will be held in Edinburgh on 11-13 November. The submission deadline for paper and tutorial proposals is 28th June so you have just one week to send us your ideas: http://ldapcon.org/2015/?page_id=5 Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: group email addresses
On Wed, Jun 17, 2015 at 04:37:36PM -0400, Brendan Kearney wrote: i have done some reading, and it seems that no official standard exists for group email addresses. to that end, i am looking to enlighten myself about what is done to provide mail addresses for groupOfNames groups. Are you just trying to add a 'mail' attribute to the group entry, or do you want the MTA (mail system) to use LDAP data to expand the mailing list? Adding the mail attribute is quite simple: define an AUXILIARY object class that permits the attribute, add that to the group entries, and you can then add the mail attribute. Doing group-based mail expansion takes more work, and really depends on what MTA you are using. You would need to configure the MTA to recognise the groups as valid list-expansion targets. It would then read the group and fetch the mail attribute from each member entry to construct the list. If the MTA cannot do this two-stage process itself, you could consider using the dynlist overlay in slapd to collect the members' mail addresses into the group entry itself. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: getent passwd only catch local user passwd
On Thu, Apr 30, 2015 at 01:06:54AM +, Yingbo Li wrote: If you find anything wrong, please let me know. I can only configure the client side, the LDAP server controlled by IT. You need to find out what each component in the stack is doing. If you have access to the LDAP server logs, try looking there to see what operations are performed. If not, consider setting up your own LDAP server so that you can run it at a high log-level. Another way to check LDAP operations is to use tcpdump and/or wireshark to capture and analyse network traffic. You will need to disable TLS for that to be useful. There is a fair amount of advice about debugging SSSD issues on the web, e.g.: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html https://fedoraproject.org/wiki/How_to_debug_SSSD_problems I would advise turning OFF nscd. It is not helpful when sssd is in use, and can cause great confusion and problems of its own. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: getent passwd only catch local user passwd
On Tue, Apr 28, 2015 at 07:49:07PM +, Yingbo Li wrote: I am new to LDAP. The company’s IT own LDAP server, I tried to configure openldap client but failed. My OS is CentOS 7, openldap is 2.4.39. I configured ldap and ldaps. I can use ldapsearch to find out full ldap info of my LDAP account. I configured with authconfig-tui. I also modified /etc/pam.d/ system-auth and password-auth, change pam_sss.so to pam_ldap.so. While when I tried getent passwd, I can only find local users. I cannot su to my LDAP account. Why? You have probably messed up the config by making those changes. CentOS 7 expects to use SSSD to access LDAP: it provides useful services and isolates system processes from the LDAP service so you should not try to bypass it. Lots of useful information here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Deployment_Guide/index.html#SSSD-Introduction Rather than editing config files directly, try to get a basic system running by using the authconfig command. This should make sure that you have a consistent setup. Better still, select LDAP authentication when you install the system and let the install wizard help you through the process. If your LDAP service places size limits or restrictive access-control on the data you may need to create an account for SSSD to bind with so that it can bypass the limits. This is not really an OpenLDAP problem, so you are likely to get more detailed help on a Red Hat or CentOS mailing list or forum. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Antw: Re: Slapd running very slow
Did you get to the bottom of this? On Thu, Apr 23, 2015 at 08:29:48PM +1000, Geoff Swan wrote: On 2015-04-23 5:56 PM, Howard Chu wrote: In normal (safe) operation, every transaction commit performs 2 fsyncs. Your 140MB/s throughput spec isn't relevant here, your disk's IOPS rate is what matters. You can use NOMETASYNC to do only 1 fsync per commit. Decent SAS disks spin at 10,000 or 15,000 RPM so unless there is a non-volatile memory cache in there I would expect at most 15000/60 = 250 fsyncs per second per drive, giving 125 transaction commits per second per drive. OK. I ran a reduced version of test script (20 processes each performing 40 read/write operations) with normal (safe) mode of operation on a test server that has 32GB RAM, and everything else identical to the server with 128GB. So that is just 800 operations taking 60s? A quick test using vmstat at 1s intervals gave the following output whilst it was running. procs ---memory-- ---swap-- -io -system-- --cpu- r b swpd free buffcache si sobibo in cs us sy id wa st 20 00 32011144 167764 33041600 115 40 56 0 0 99 1 0 0 00 31914848 167764 33042400 0 1560 2594 2130 2 1 97 0 0 0 00 31914336 167764 33042400 0 1708 754 1277 0 0 100 0 0 0 00 31914508 167772 33042000 0 2028 779 1300 0 0 99 1 0 The script took about 60s to complete, which is a lot longer than expected. It appears almost all I/O bound, at a fairly slow rate (1500 blocks in a second is 6MB/s). As you say, it is IO bound (wa ~= 100%). Stop worrying about MB/s: the data rate is irrelevant, what matters is synchronous small-block writes and those are limited by rotation speed. Are you absolutely certain that the disks are SAS? Does your disk controller believe it? I had big problems with an HP controller once that refused to run SATA drives at anything like their full speed as it waited for each transaction to finish and report back before queuing the next one... Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: All entries belong to the top object class?
On Tue, Apr 28, 2015 at 10:21:25AM +0530, dE wrote: No. 'top' is defined in RFC4512: ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) so every entry MUST contain an objectclass attribute. It does not say anything about any other attributes. Yeah, so that's the question, can any attribute which is in the MAY of the top object class be added to any entry in the DIT regardless of what object class it belongs to? The top object class does not have any MAY attributes. If it did then yes you could use them in any entry in the DIT as all normal entries are members of top. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Ldap challenge
On Wed, Apr 22, 2015 at 08:08:11PM +, Ross, Daniel B. wrote: What i need to do is continue to use the campus usernames and passwords but present the Data in a format that my linux/unix hosts can use. Is this possible? Probably, but I don't think you have given us enough information so far. i.e. userid would still be samwise but instead of a bizzarre OU= monkeypeople,dc=example,dc=com I want it to present as people,dc=example,dc= com. I assume the latter DN should be O=people,dc=example,dc=com If this is your main problem then it may not need solving on the server side. There is no fixed rule about the structure of a base DN used for Linux and Unix LDAP authentication. You should be able to work with any DN structure, provided that you know where to base your searches and provided you can do one-level or subtree searches on the AD service to find what you need. I looked at referral and aliasing but it does not seem to be doing what I am trying to do. Passthrough authentication looks close but I cant find sufficient documentation to actually configure a system to use it. Does the campus AD service contain everything that Linux/Unix would need? e.g. does it have: Username (almost certain - called samAccountName in AD) Unix numeric UID Unix numeric GID Unix homedir Unix shell Something to use for GECOS (optional) It does not matter what those attributes are called in AD as you can set the clients to work with whatever you have, but they *do* have to be present. It used to be necessary to load a Microsoft package called SFU (Services For Unix) to support this, but I think more recent versions of AD already have schema for it by default. If you don't have at least that set of attributes with sensible values to work with then you will have to maintain a parallel or overlay directory service. There are several ways to do that, so let's start by establishing what you have! Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: All entries belong to the top object class?
On Sat, Apr 25, 2015 at 05:58:43PM +0530, dE wrote: Does adding of the top object class (implicitly) make it possible to add all attributes in the DIT to the entry? I'm talking about attributes which are out of the 'MAY' in the most subordinate object class the entry belong to. If you really want to permit *any* attribute to be added to an entry, then you can add the ExtensibleObject objectclass. In general this is a *bad* thing to do. See RFC4512 section 4.3 for the definition. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: separate loglevels for different databases?
On Mon, Apr 27, 2015 at 05:19:54PM +0200, Meike Stone wrote: I've configured two different databases (one ldap, one bdb) in openLDAP. Is it possible, to configure separate loglevels for each database? maybe at least different logfiles? loglevel / olcLogLevel is a global option, so no I'm afraid you cannot do this. If you really want different logging you will have to put each backend in a separate server instance and join them together with a third using back-ldap or back-meta. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Ldap challenge
On Mon, Apr 27, 2015 at 06:27:39PM +, Ross, Daniel B. wrote: ismemberof does not exist we have to use memberof Memberof is fairly common. I don't think I have ever found a system that used 'ismemberof'. Note that maintaining memberof takes some work so it is not enabled on all LDAP servers by default. nsUniqueId we have to use objectGUID What do you use nsUniqueId for? Probably not a problem anyway as you may be able to use other similar attributes as you mention above. no uniqueMember again can only use memberof. uniqueMember and memberOf have completely different use-cases: uniqueMember is used just like 'member' in most cases, to indicate which entries are members of the group that it appears in. memberOf indicates which groups the entry that it appears in is a member of (i.e. it is the inverse mapping). while there is a guarantee of person there is not the same for Posixaccount or shadowaccount. Ah - if you lack those attributes then AD is certainly not going to do the job on its own. While I have been able to get linux with SSSD to work, to some extent, with this its rather hit and miss and the Solaris systems just wont work at all. This is why I was hoping to be able to use the campus for the username and password, and then provide the rest from a local ldap server. It doesnt sound like this is really possible. Yes - it should be possible but it will take a bit more work. saslauthd did not work at all with the MS LDS. Did you try following the instructions here?: http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authentication Note that you will need the DN and password of an existing AD user to allow saslauthd to do LDAP searches on AD. You can try the ldapsearch commands from section 14.5.3 without any other setup to test that you have a good user account. In principle it may be better to do Kerberos authentication against AD rather than LDAP, but I didn't have a Kerberos server handy when I wrote that bit. What is a parallel or overlay directory service? Parallel would be where you replicate some subset of data from AD into a local LDAP server, which then operates as a self-contained system. You could have the replication process create or look up Unix-specific attributes like UID and GID for new accounts. Overlay would be where you use what you can get from AD, and put a translucent overlay on top containing Unix-specific data that you administer locally. In either case you need to decide how to handle password checking and account locking. All of my customers so far have chosen the parallel approach, as that allows the Unix LDAP to continue working if it loses access to AD. Ideally this includes installing a module on the AD Domain Controllers that detects password changes and forwards them immediately to the Unix LDAP. I have generally used Microsoft's SFU password-capture module for this as AD admins seem happier to install Microsoft code than things from other sources. It does have its problems though, and the code quality of the Unix end that they provide leaves a lot to be desired. I believe newer AD versions come with an updated version of this built in, but I have not tested it. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: All entries belong to the top object class?
On Mon, Apr 20, 2015 at 11:06:07AM +0530, dE wrote: I'm concerned about the attributes. Does adding of the top object class (or person) add all attributes to the entry? No. 'top' is defined in RFC4512: ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) so every entry MUST contain an objectclass attribute. It does not say anything about any other attributes. In any case, objectclasses do not directly add attributes to entries. They do permit (MAY) or require (MUST) certain attributes. It is up to the user or application to supply values for MUST attributes and for any MAY attributes that you want to use. LDAP does not support 'present but empty' attributes, so there must be a non-null value in each MUST attribute. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
LDAPCon 2015
LDAPCon 2015 Please note the new submissions address The fifth International Conference on LDAP and Directory Services will be held in the UK at the University of Edinburgh School of Informatics Forum. Tutorials: 11th November 2015 Conference: 12th and 13th November 2015 Call for papers and tutorials = Topics You are using LDAP in interesting projects? You do LDAP client or server development? You have used LDAP in a new way? You do identity and access management on top of LDAP? Why not share your ideas and experiences with others? We are looking for speakers who are willing to talk about any topic related to LDAP and identity management, including: LDAP technology implementation (Servers, API, User interfaces etc.) LDAP Usage (Schema, Security, Operations, Scaling, big data, etc.) LDAP related technologies (PKI, XACML, SAML, etc.) LDAP and Beyond (IAM, Identity Federation, Authentication on the web, etc.) Best Practices for directory services. Accepted talks will be grouped into tracks such as a standards/development and deployment/administration. Deadlines Important Dates Submission Deadline: 28th June Author Notification: 10th July Final Papers due: 10th October 2015 Tutorials: 11th November 2015 Conference: 12th-13th November 2015 Talk Submissions Main presentations should last about 45 minutes including discussion; we will also provide smaller slots of 15 minutes and 5 minutes for poster presentations or lightning talks. Please tell us which duration you prefer when proposing your talk. The talk must be in English. The one and only way to submit your abstract (approximately 200-800 words, accompanied by your biography of about 100-300 words) is via email to submissions2...@lists.ldapcon.org. Abstracts must reach the Program Committee by 28th June 2015. Early submission is encouraged. We already have several papers. All abstracts will be reviewed by the program committee. For accepted talks we expect you to submit slides and/or a paper of approximately 2-10 pages (A4 or US Letter format, 25mm borders, preferably LaTeX source or OpenOffice). For 5-minute talks, a brief abstract is required. A short paper, slides or a poster should be provided for accepted talks. We will provide display boards for posters throughout the conference. By submitting a paper you grant the conference organizers the non-exclusive right to publish your paper in the conference proceedings and on the website; you maintain the right to publish it elsewhere at your discretion. Tutorial Submissions We are looking for high-quality tutorials on LDAP and related subjects, at any level from introductory to advanced. Tutorial length can range from an hour to a full day. Wireless Internet access will be available if required. The purpose of the tutorials is focussed education, so they should cover established topics and best practice rather than presenting new work. Tutorials will be on Wednesday 11th November 2015. The Programme Committee has an open mind about the format of the tutorial day, but has a limited number of rooms available. Make your proposal early and we will aim to build an attractive programme for the day. Expenses Speakers get free access to the conference, including the social event. If requested in advance we will provide accommodation for speakers. Travel expenses might also be covered in special cases. If you need this, please contact us early so we can try to arrange it. Website http://ldapcon.org/2015/ Contacts General enquiries: enquir...@lists.ldapcon.org Paper/Tutorial submissions:submissions2...@lists.ldapcon.org -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: i am new to ldap plz help i have provided ldif file and simple authentication code
On Wed, Feb 11, 2015 at 11:19:40AM +0530, Bharath K wrote:
this is my java code where i can get output for none authentication when i
use simple authentication its not working...
env.put(Context.SECURITY_AUTHENTICATION, simple);
env.put(Context.SECURITY_PRINCIPAL, cn=Manager,
ou=People,dc=example,dc=com);
That DN is not in the LDIF data that you posted.
It might be set as the rootDN for the database, but we need to see the
OpenLDAP configuration to know whether it is right (either the
slapd.conf file or an LDIF dump of everything under cn=config
depending on which config system you are using).
env.put(Context.SECURITY_CREDENTIALS, ldap123);
// env.put(Context.SECURITY_CREDENTIALS,
{SSHA}rZe5WkunQdmRkyCcEHu9g6VsqRecnzIa);
Note that you must send the plain-text password. The SSHA hash is only
used in server config or in LDAP entries.
this is my LDIF file
# nagios, People, example.com
dn: uid=nagios,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: nagios
sn: nagios
givenName: nagios
cn: nagios
displayName: nagios
uidNumber: 500
gidNumber: 500
userPassword:: secret
If you want to set the password to 'secret' then you should only have
one colon:
userPassword: secret
Using :: means that the data is Base-64 encoded.
Please post the OpenLDAP configuration so that we can check the DNs
and passwords.
Please also reload the data with the correct userPassword values and try:
env.put(Context.SECURITY_PRINCIPAL,
uid=nagios,ou=People,dc=example,dc=com);
env.put(Context.SECURITY_CREDENTIALS, secret);
VERY IMPORTANT: please post the actual data and the real passwords
that you are using to test with. If they are really secret, then
change them to something trivial BEFORE doing the tests.
Andrew
--
---
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/+44 1628 782565 |
---
Re: plz provide me any simple authentication code in ldap
On Fri, Feb 06, 2015 at 10:42:45AM +0530, Bharath K wrote: To: Andrew Findlay andrew.find...@skills-1st.co.uk Please keep your replies on-list so that others with similar problems can learn from the archive. Subject: Re: plz provide me any simple authentication code in ldap i configured openldap and i added user in ldif file,,without authentication its working.. when i use simple authenticaion its not working its showing as invalid credentials so what might be the problem??.. I expect the credentials that you are presenting to the LDAP server are invalid (the DN or the password is wrong or is missing). If you want help you need to supply more information. Your code does not include the DN and password that you are trying to use, and you have not supplied any information about the entry that you are trying to bind as. You need to tell us or we cannot help you. When you run this program, what do you put on the command line? Did you turn up the logging as I suggested? What is in the log? Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Openldap migration from 2.4.11 to 2.4.40 for 4-way multimaster servers
On Wed, Feb 04, 2015 at 08:56:08AM +, Gary Ho wrote: What's the proper procedure of migrating the data from servers A,B,C,D to W,X,Y,Z ? My procedure is as follows : - Export data from server A using slapcat command. - Delete the first 6 lines of the ldif files (the lines contains the contextCSN). - Shutdown the process slapd in servers W,X,Y,Z and remove all the openldap data files under /usr/local/var/openldap-data. - Import the ldif files to server W, then start the slapd process in server W. - Export the ldif files from server W. - Import the ldif files to server X,Y,Z respectively. - Start the slapd process in X,Y,Z. I don't think it needs to be that complex. I would do something more like this: - Shutdown the process slapd in servers W,X,Y,Z and remove all the openldap data files under /usr/local/var/openldap-data. - Export data from server A using slapcat command. - Import the data to each of the new servers, taking care to use the -w flag on slapadd. - Start the slapd process in W,X,Y,Z. Another option is to add the new servers one at a time to the existing topology (which would still involve export and import of LDIF if there is a significant amount of data). You could then migrate the clients gradually and eventually remove the old servers. This would achieve transition without a break in service. What I observe is that all four servers then has 100% CPU and never drop back to idle ? I have seen something like that before where the new servers were trying to fetch all entries from all other servers. They were spinning on locks as each syncrepl consumer thread was trying to write the same set of entries. Importing with the -w flag should reduce the risk of that. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: plz provide me any simple authentication code in ldap
On Thu, Feb 05, 2015 at 09:56:19AM +0530, Bharath K wrote: Subject: plz provide me any simple authentication code in ldap below is my codeby executing this i am getting as error as invalid credentials This is apparently the same question that you asked on 23rd January, but this time you have provided even less information. It does not appear to be an OpenLDAP question at all: more of a Java programming question so maybe there is a better list to ask. I am not a Java programmer so I cannot help much with the code. All I can suggest is that if you are using an OpenLDAP server you should turn up the logging to include at least 'stats' and 'stats2' and post the log entries that appear when you run your program. You will also need to post the entry that you are trying to bind as. Logging is controlled by the global option 'loglevel' if you are using file-based config, and by the olcLogLevel attribute of cn=config if you are using slapd-config. File based: loglevel stats stats2 or in LDIF: dn: cn=config ... olcLogLevel: stats stats2 Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: bind UID in DN instead of CN
On Fri, Jan 30, 2015 at 06:36:29PM +0100, Dennis wrote: This fails because it tries to accomplish this by using dn=uid=..., but as shown in phpldapadmin the dn is cn=Test Testuser,ou=users,dc=dmp,dc=... Therefore the distinguished name for dn=uid=...,ou=users,dc=dmp,dc=... doesn't exist (the user has a uid of course). Therefore my question is, is there a possibility to change / to configure openldap to use / allow the uid instead of the cn? You can use any locally-unique attribute value in a DN, but each entry can only have one DN. So: you can change your DIT design to use uid=...,ou=users,dc=dmp,dc=... if you want to, but then anything that is assuming the existing DN structure wil break! In this case I would say that your management application is at fault. It should not be assuming that it can make a DN by tacking the UID value onto a fixed suffix. If all it knows is the UID then it should first search for the entry using the UID in the search filter. The search result will include the DN of any entry that is found, so it is then easy to work on that entry. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Large Number of Transactions x Low performance
On Thu, Jan 29, 2015 at 07:49:29PM +, Alessandro Lasmar Mourao wrote: I work in a company that has 140,000 registered users in OpenLDAP. This OpenLDAP is used for authentication of our internal systems. In our tree of groups we have the systems and below the each system there are the groups' authorization (systems profiles). The user is bound in each group according to position, function and department in the company. When a user replaces another user hierarchically higher, this user is taken from the respective group (that he belonged) and registered in user_group with the highest hierarchy. This movement in the company is very common, and this is the cause of our problems. We have a group with 50,000 registered users, and when we need to delete a user of that group or add a new one, OpenLADP takes up to 6 minute to effect the transaction. Assuming that these groups are the conventional 'single entry with many values of the member attribute' type, you should turn on the 'sortvals' global option: sortvals attr [...] Specify a list of multi-valued attributes whose values will always be maintained in sorted order. Using this option will allow Modify, Compare, and filter evaluations on these attributes to be performed more efficiently. The resulting sort order depends on the attributes' syntax and matching rules and may not correspond to lexical order or any other recognizable order. I cannot offhand remember whether you need to re-load the data for that to take effect. We have a tool (BMC Identity Management (formerly Control-SA)) that automates the transactions, but due to delay in the transactions are with a row of 100,000 operations of insert / delete to perform. Check how it modifies the groups. If it rewrites the whole set of 'member' attributes each time then you are forcing the server to re-index every value. The efficient way to do this is to specify the value that you want to remove or the one you want to add. It should be very quick. Also look at your replication setup. With this sort of data you really do need delta mode. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
LDAPCon 2015 Call for Papers
LDAPCon 2015 The fifth International Conference on LDAP and Directory Services will be held in the UK at the University of Edinburgh School of Informatics Forum. Tutorials: 11th November 2015 Conference: 12th and 13th November 2015 Call for papers and tutorials = Topics You are using LDAP in interesting projects? You do LDAP client or server development? You have used LDAP in a new way? You do identity and access management on top of LDAP? Why not share your ideas and experiences with others? We are looking for speakers who are willing to talk about any topic related to LDAP and identity management, including: LDAP technology implementation (Servers, API, User interfaces etc.) LDAP Usage (Schema, Security, Operations, Scaling, big data, etc.) LDAP related technologies (PKI, XACML, SAML, etc.) LDAP and Beyond (IAM, Identity Federation, Authentication on the web, etc.) Best Practices for directory services. Accepted talks will be grouped into tracks such as a standards/development and deployment/administration. Deadlines Important Dates Submission Deadline: 28th June Author Notification: 10th July Final Papers due: 10th October 2015 Tutorials: 11th November 2015 Conference: 12th-13th November 2015 Talk Submissions Main presentations should last about 45 minutes including discussion; we will also provide smaller slots of 15 minutes and 5 minutes for poster presentations or lightning talks. Please tell us which duration you prefer when proposing your talk. The talk must be in English. The one and only way to submit your abstract (approximately 200-800 words, accompanied by your biography of about 100-300 words) is via email to submissi...@lists.ldapcon.org. Abstracts must reach the Program Committee by 28th June 2015. Early submission is encouraged. All abstracts will be reviewed by the program committee. For accepted talks we expect you to submit slides and/or a paper of approximately 2-10 pages (A4 or US Letter format, 25mm borders, preferably LaTeX source or OpenOffice). For 5-minute talks, a brief abstract is required. A short paper, slides or a poster should be provided for accepted talks. We will provide display boards for posters throughout the conference. By submitting a paper you grant the conference organizers the non-exclusive right to publish your paper in the conference proceedings and on the website; you maintain the right to publish it elsewhere at your discretion. Tutorial Submissions We are looking for high-quality tutorials on LDAP and related subjects, at any level from introductory to advanced. Tutorial length can range from an hour to a full day. Wireless Internet access will be available if required. The purpose of the tutorials is focussed education, so they should cover established topics and best practice rather than presenting new work. Tutorials will be on Wednesday 11th November 2015. The Programme Committee has an open mind about the format of the tutorial day, but has a limited number of rooms available. Make your proposal early and we will aim to build an attractive programme for the day. Expenses Speakers get free access to the conference, including the social event. If requested in advance we will provide accommodation for speakers. Travel expenses might also be covered in special cases. If you need this, please contact us early so we can try to arrange it. Website http://ldapcon.org/2015/ Contacts General enquiries: enquir...@lists.ldapcon.org Paper/Tutorial submissions:submissi...@lists.ldapcon.org -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Antw: Re: OpenLDAP Replication Issue
On Fri, Jan 23, 2015 at 04:10:47PM +0100, Ulrich Windl wrote: The answer is the same: you must start by updating to a current version of the OpenLDAP server. There are a lot of bugfixes so this will probably solve your problem. I have a logic problem with this: If the update will only probably solve the problem, why must he update? ;-) Because until he does, people on this list will assume that the problem is due to a bug that has already been fixed. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: I am new to ldap and i dont know much about ldap simple authentication could you plz help me and give some suggestions......and below is the simple code which i tried and ther is also uid test 12
On Fri, Jan 23, 2015 at 10:32:18AM +0530, Bharath K wrote: Subject: I am new to ldap and i dont know much about ldap simple authentication could you plz help me and give some suggestions..and below is the simple code which i tried and ther is also uid test 12 which i want to authenticate It is best to put your question in the body of the message rather than all in the subject line. env.put(Context.SECURITY_PRINCIPAL,args[0]); env.put(Context.SECURITY_CREDENTIALS,args[1]); What values did you supply for these? What happened? What did you expect to happen? dn: uid=nagios,ou=People,dc=example,dc=com ... userPassword:: dn: uid=test1,ou=People,dc=example,dc=com ... userPassword:: dn: uid=test2,ou=People,dc=example,dc=com ... userPassword:: All three accounts appear to have blank passwords. LDAP servers will not normally allow authentication with a blank password. For testing, you can easily add passwords like this: userPassword: secret Note the single ':' character. If you use '::' then the data is expected to be in Base 64. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: OpenLDAP Replication Issue
On Thu, Jan 22, 2015 at 03:49:52PM +0100, sofien BLOUZA wrote: I have the same problem, I'm running on OpenLDAP 2.4.39-8.el6. Sometimes the ldap server is blocked ? Can you help me i have the same ldap replication topology The answer is the same: you must start by updating to a current version of the OpenLDAP server. There are a lot of bugfixes so this will probably solve your problem. You can build from source: http://www.openldap.org/software/download/ Or you can use the LTB RPMs: http://ltb-project.org/wiki/documentation/openldap-rpm Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: OpenLDAP Replication Issue
On Wed, Jan 21, 2015 at 01:30:51PM -0800, Tony S. Wu wrote: We have 5 servers running OpenLDAP, 001 - 005. Server is CentOS 6.4, LDAP version is openldap-servers-2.4.23-32.el6_4.1.x86_64, current replication 2.4.23 is a very old version - released 2010/06/30. There have been about 750 updates to the code-base since then: http://www.openldap.org/software/release/changes.html It is very unlikely that RedHat have incorporated all those fixes into their distro, so you will not get much help here if you continue to use their version. Your first move should be to build OpenLDAP from current source: http://www.openldap.org/software/download/ You can easily set it to install in /usr/local or some other place of your choice to avoid over-writing the RedHat version so that you can run tests and still be able to revert if you need to. I would advise that you use a new location to store the database, and that you load it from LDIF using slapadd. Don't try to use new code with the existing database (though it may well work as the version is similar enough). Building from current source gives you the opportunity to switch to LMDB so you don't even need to link the Berkeley DB libraries. LMDB (database mdb) is highly recommended. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: LDAP Search with non-existent attributes
On Fri, Jan 16, 2015 at 03:34:11PM +0100, Dirk-Willem van Gulik wrote: W’re comparing various LDAP server setups; and we are wondering what the ‘correct’ search result is for a search which is done such as '(|(|(|(givenname=fred*)(sn=fred*)(mail=fred*)(cn=fred*) You have a mismatch of parentheses there. The filter should be: (|(givenname=fred*)(sn=fred*)(mail=fred*)(cn=fred*)) [ Note that one '|' can be followed by a list of one or more filters - it is not a dyadic operator - see RFC4515 section 3 ] Where are the 'non-existent attributes'? All of those listed in the search filter are in the standard schema. Your sample entry below may not have values for all of them, but as the sub-filters are combined with OR that would not matter. Providing an attribute-value assertion containing an outlandish attribute name just might provoke a different response, but the standard says that such elements in a filter should evaluate to UNDEFINED and the OR operator would then treat the element as FALSE. in a situation where we have records which do not have a certain attribute (e.g. no givenname or cn) — e.g. a record as light weight as: dn: uid= 1234 objectClass: person uid: 1234 sn: fred fred telephoneNumber: 1234 That would not be a valid entry as objectClass person requires both cn and sn. It *might* be a valid answer to a search - e.g. if access-control prevented disclosure of cn. As we notice that some servers will return this given above query; and some do not. In principle the entry matches the filter so it should be returned. However, the '|' (OR) operator poses a significant problem for a server, particularly where there are a lot of entries and one or more of the attributes in the search string are not indexed. This can force the server to inspect every entry in its database individually which is a lot of work, so servers may refuse to do it. For some servers, an attribute type is treated as 'not indexed' if there are no entries with a value for that attribute type, even if indexing is enabled. [ I think OpenLDAP used to do this but I have not checked recently ] The actual result that you would get from the server in this case depends to some extent on the security stance of the developers and of the manager of the server instance. I can see valid arguments for several results: adminLimitExceeded busy unwillingToPerform success - along with zero or more entries And I cannot find the exact spot in the RFC where the ‘correct’ behaviour is mentioned. RFC4511, 4.5.1.7. SearchRequest.filter As we notice that some servers will return this given above query; and some do not. It would be interesting to have more detail on exactly what you did and what results you found. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: back-sql deployment woes
On Wed, Jan 07, 2015 at 09:59:28AM +0100, Dieter Klünter wrote: You may use back-sql as a read only subordinate database, but performance is limited to the sql engine. Be aware that your are on your own risk. Another option would be to use back-sock and write a separate server process to translate between the back-sock protocol (extended LDIF) and SQL. You should get better performance (if your server programming is good) and if something goes wrong there is less code to debug: back-sock has under 1500 lines of C, where back-sql has over 11000... There are still many caveats though: limited ACLs, fundamental mismatch in data model, poor performance and resource usage when compared with back-mdb etc... Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Can't contact LDAP server (-1) additional info: error:14077410:SSL routines :SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
On Sat, Nov 22, 2014 at 01:18:18PM +0100, Ferenc Wagner wrote: Date: Sat, 22 Nov 2014 13:18:18 +0100 From: Ferenc Wagner wf...@niif.hu To: wailok tam wailok...@yahoo.com Cc: openldap-technical@openldap.org Subject: Re: Can't contact LDAP server (-1) additional info: error:14077410:SSL routines :SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure Sender: openldap-technical openldap-technical-boun...@openldap.org wailok tam wailok...@yahoo.com writes: ldapmodify -x -W -D 'cn=root,dc=ier,dc=hit-u,dc=ac,dc=jp' Enter LDAP Password: ldap_bind: Can't contact LDAP server (-1) additional info: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure Maybe you want to use SSLv3, and the server does not support it? I suspect that the ldap.conf file has a URL of the form ldaps://server but the config fragment we saw did not have any TLS config so ldaps: will not work. Quick test: ldapmodify -x -h ldap://server/ -W -D 'cn=root,dc=ier,dc=hit-u,dc=ac,dc=jp' Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: slapd read_config / interface bind errors
On Wed, Nov 19, 2014 at 04:09:32PM -0500, Jason Swank wrote: What about the interface bind conflict when ldap:// is specified? Is that expected behavior? Yes. ldap:/// binds to port 389 on *all* IPv4 and IPv6 interfaces. If you also have ldap://hostname/ then you are trying to bind at least one of those interfaces twice. Note also that you should be using fully-qualified domain names everywhere. Simple hostnames will not work properly with TLS. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: debugging OpenLDAP client
On Tue, Nov 18, 2014 at 06:59:12PM +0200, Igor Shmukler wrote: Well, I raised this subject stating that -1 does not do what I need. -1 prints everything that OpenLDAP has got, so you need to look elsewhere if that is not enough.. I suggest Wireshark: either use it directly to capture network traffic or run tcpdump on the LDAP server or client machine and transfer the dump file to your desktop machine for analysis. If the server or client machine has a graphical display then you can do the whole job directly with Wireshark. Here is an invocation of tcpdump to do the capture: tcpdump -i eno1 -w /tmp/traffic host myclient.example.com and port 389 eno1 is the name of the network interface /tmp/traffic is the dump file myclient.example.com is the name of the server if this is run on the client host or the name of the client if run on the server Set that running and have your client code do its stuff. Break into tcpdump with control-C Copy /tmp/traffic to your desktop if necessary Open /tmp/traffic in Wireshark. You can expand the various protocol levels to get nore detail. If you drill down into the LDAP layer you will see the search request and if you drill further you will see the paged results control, cookies etc. Note that you will have to turn off encryption (SSL/TLS) on the LDAP session if you are using it (which you should be when you go into production). Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: any help on ldap_sasl_bind_s failed (53)
On Wed, Nov 19, 2014 at 07:38:02AM +, wailok tam wrote: Subject: any help on ldap_sasl_bind_s failed (53) but I am getting the error given in the title when I start the slave with splad -d sync . Replication does not work. sladp.conf of the slave: syncrepl rid=001 provider=ldap://mail.ier.hit-u.ac.jp type=refreshAndPersist interval=00:00:05:00 searchbase=dc=ier,dc=hit-u,dc=ac,dc=jp binddn=uid=replicator,ou=Users,dc=ier,dc=hit-u,dc=ac,dc=jp bindmethod=simple #bindmethod=sasl saslmech=DIGEST-MD5 #authcid=replicator credentials=secretofreplicator The two comment lines are likely to be the problem. the manpage for slapd.conf says: If a line begins with white space, it is considered a continuation of the previous line. No physical line should be over 2000 bytes long. Blank lines and comment lines beginning with a `#' character are ignored. Note: continuation lines are unwrapped before comment processing is applied. That says to me that comments inside an indented block are to be avoided. As an aside, you may not want to use DIGEST-MD5 anyway, as it requires the server to store the password in cleartext rather than hashed. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: adding VLV support to OpenLDAP 2.4.31
On Wed, Nov 12, 2014 at 01:02:36AM +0200, Igor Shmukler wrote:
Interestingly, lsof does have the following entry:
slapd 13310 openldap memREG 202,126872 409681
/usr/lib/ldap/sssvlv-2.4.so.2.8.3
Hence, it seems that sssvlv is loaded. At the same time, ldapsearch is
telling me VLV control requires server side sort control
It would appear that the sssvlv *module* has loaded, but you still have to
apply the overlay to the database that you want it to work on.
Does this mean like Quanah said that my OpenLDAP from Ubuntu server is broken?
Not necessarily. Many people on this list dislike the way that some
of the major Linux distros build OpenLDAP and the old versions of
OpenLDAP that they use, so the default setup tends to get described as
'broken'. Quanah was also referring to the fact that you had hand-edited
a file under /etc/ldap/slapd.d/cn=config - that is a very risky thing
to do and you may have caused problems that way.
In this case I think it more likely that you just need to add the overlay
to the database.
On Wed, Nov 12, 2014 at 08:38:14AM +, Chris Card wrote:
Date: Wed, 12 Nov 2014 08:38:14 +
From: Chris Card ctc...@hotmail.com
dn: olcOverlay=sssvlv,olcDatabase={1}bdb,cn=config
objectClass: olcSssVlvConfig
olcOverlay: sssvlv
olcSssVlvMax: 10
olcSssVlvMaxKeys: 5
something like
ldapadd -x -w password -D cn=config -f ldif file
As Chris says, ldapadd (or slapadd if the server is down) is the right
way to modify a config of this type. The exact LDIF required will
depend on your database setup: Chris has assumed that you want the
overlay on the first non-config database and that it is a bdb.
If your setup is different then the DN will have to change.
Note also that bdb is deprecated. If you continue to use the binaries
shipped with Ubuntu then you should at least consider swapping to hdb.
Ideally you should build the latest OpenLDAP from source and use mdb.
Changing to a different database type requires dumping all data to LDIF
text files and re-loading it in the new database, so this is not something
to be undertaken until you are more familiar with OpenLDAP.
Andrew
--
---
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/+44 1628 782565 |
---
Re: adding VLV support to OpenLDAP 2.4.31
On Wed, Nov 12, 2014 at 12:41:46PM +0200, Igor Shmukler wrote: I am also curious about another part of the olcDatabase parameter. How do I know whether to use bdb or hdb? I don't care either way of course. I just need my test server to work, so I could proceed with my main duty - programming. For a test server it probably does not matter which database you use unless you need to load large amounts of data, or do unusual things like rename whole subtrees (bdb cannot do that). For a production server using current OpenLDAP code, mdb is the first choice. If you are forced to use older software then hdb may be safer. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: export directory in LDIF format
On Tue, Nov 11, 2014 at 07:46:19AM -0500, Jerry wrote: This is the actual code I am using in CRON: nice /usr/local/sbin/slapcat -f /usr/local/etc/openldap/slapd.conf -b dc=MyDomain,dc=net -l usr/home/gerard/LDAP_Backup/MyDomain.net.ldif Try running it under 'strace' so you can see what file it really tried to open. e.g. strace -o /tmp/slapcat-trace.`date +%Y%m%d%H%M` /usr/local/sbin/slapcat -f /usr/local/etc/openldap/slapd.conf -b dc=MyDomain,dc=net -l usr/home/gerard/LDAP_Backup/MyDomain.net.ldif Originally, I had created a Bash script and had CRON call that script; however, when things were not working as planned, I thought that might be the problem. However, it does not appear to be so. Any ideas what I could be doing wrong? Remember, this only happens when there has been several hours of inactivity; otherwise it works fine. Do any of the paths involved in the config go through NFS or automount points? Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: adding VLV support to OpenLDAP 2.4.31
On Tue, Nov 11, 2014 at 11:48:59PM +0200, Igor Shmukler wrote: Thank you for your answer. I spent quite a lot of time reading various man pages including the one for slaps.conf(5), of course. As I mentioned, there is no slapd-config on my system. [How] is it possible that system is configured cn=config without it? slapd-config is a manual page, not an executable. man slapd-config Describes the LDAP/LDIF configuration method man slapd.conf Describes the flat text-file configuration method Both methods configure the same things, so those pages are quite similar. The keywords / attribute names are different though, so make sure you read the right one for the method you are using. Is there a way to determine whether slapd.conf is used and where the daemon is trying to find it, short of doing a system call trace? Use 'ps ax | grep slap' to see whether there are any command-line options applied to the slapd process. If there are, look them up in 'man slapd' taking particular note of the -f and -F options. If those options are not present then the daemon will use the default config database (see slapd-config above) or, failing that, will use the default config file (see slapd.conf above). Each of those manual pages starts with a note of exactly where the default database or config file will be found on your system. Also, is there a command to list loadable modules in use? 'lsof -p slapd PID' perhaps :-) Modules can be backends or overlays. I cannot think of a single command that finds all loaded slapd modules. You can find what backends and overlays are available/active by browsing under cn=monitor. Similarly you could search under cn=config to find what the config says *should* be loaded. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: LDAP Crafted Search Request Access Allowed
On Thu, Oct 30, 2014 at 09:54:57AM -0300, Net Warrior wrote: I suspect that you do not want that. It would force every client to have a client-side X.509 certificate. Good for secure authentication, but more effort to manage than most people are prepared to handle. Is it because of the certificte expiration or something like that tha's hard to mantain? Yes. It is worth considering though, provided you have a well-organised system for distributing and installing new client-side certificates. You will also need to make sure that the admin tools you use can work with client-side certs. That is because you tried to add it to a database but it is a global option. I added to the global section cn=config and do not see it. Odd. If you use ldapadd to do this then it should either work or return an error code. Are you really using the BDB database? It has been deprecated for some time now. I would suggest using MDB Yes my bad, after I went to production, I was told that backend was deprecated, is there any doc related to migrate from one backend to another or should I reconfigure the whole database from scratch ? The safest approach is to slapcat each of your databases into LDIF files then configure new MDB databases and slapadd the data. You will find that loading MDB with slapadd -q is extremely fast. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: LDAP Crafted Search Request Access Allowed
On Thu, Oct 30, 2014 at 08:11:31AM -0300, Net Warrior wrote:
1 ) Added tls_reqcert demand to the client side
2 ) Configured a user to bind instead of anonymous
binddn cn=ldapuser,Ou=Users,dc=server,dc=com
bindpwd :$6$oZ8qYohy$lU0sYJXInOO1ISO4WKgzeuDyyFh9a
Good.
3 ) Added olcTLSVerifyClient:demand to server side:
I suspect that you do not want that. It would force every client to
have a client-side X.509 certificate. Good for secure authentication,
but more effort to manage than most people are prepared to handle.
Object added to server:
dn: olcDatabase={2}bdb,cn=config
changetype:modify
add: olcTLSVerifyClient:demand
Still I did not corrected my ACL but I do not see olcTLSVerifyClient:demand
reflected on my configuration
That is because you tried to add it to a database but it is a global option.
Are you really using the BDB database? It has been deprecated for some time now.
I would suggest using MDB.
Andrew
--
---
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/+44 1628 782565 |
---
Re: LDAP Crafted Search Request Access Allowed
On Wed, Oct 29, 2014 at 08:19:03AM -0300, Net Warrior wrote: 200 Servers and 20 users OK - that means that you will not have problems with the default limits on result-set size (500 entries). I hope you don't really bind with the ROOTDN account! NO! and I have a user to test the configuration but I do not use it to bind purposes, but I could if I knew how to configure it. As you have quite a lot of servers and a policy of hiding all data from anonymous users, I would suggest having more than one LDAP-client account. Either create one per client server, or one per group of similar servers. I would suggest putting the client accounts in a dedicated part of the LDAP tree, so it might look like this: ou=Users,dc=server,dc=com POSIX user accounts ou=Groups,dc=server,dc=com POSIX groups ou=Clients,dc=server,dc=com Client machine accounts You need to get all your client machines to bind with their account DN and password before you start changing ACLs. Config file entries will look something like this: binddn cn=server1,ou=Clients,dc=server,dc=com bindpw SomeLongAndSecurePassword You should also add: tls_reqcert demand and you may want to consider restricting the connection to high-grade ciphers e.g.: tls_ciphers HIGH:MEDIUM:@STRENGTH Both, client and server side right? Yes, but the keyword for slapd.conf is TLSCipherSuite and for ldap.conf it is TLS_CIPHER_SUITE Once you have *all* the clients using TLS and binding with their client account and password, you can start on ACLs. If your logging includes the 'stats' category (256) you will be able to see TLS setup and bind in the logs, e.g.: Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 fd=26 ACCEPT from IP=[::1]:43386 (IP=[::]:389) Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 STARTTLS Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 RESULT oid= err=0 text= Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 fd=26 TLS established tls_ssf=128 ssf=128 Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 BIND dn=cn=client234,ou=Clients,dc=server,dc=com method=128 Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 BIND dn=cn=client234,ou=Clients,dc=server,dc=com mech=SIMPLE ssf=0 Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 RESULT tag=97 err=0 text= After all that, the ACLs turn out to be really simple! Something like this will probably be close to what you need for the main database: access to attrs=userPassword by self =w by * auth access to * by users read access to * by * none If you have a replica server then you will need to add an ACL giving read access to all attributes. This should go right at the top of the list, and will look something like this: access to * by dn.exact=cn=replicator,ou=Clients,dc=server,dc=com read If you are using the Monitor database then you should probably protect it like this: access to dn.subtree=cn=Monitor by users read by * none And to make sure that critical stuff like the root DSE and the schema can be read by everyone, add this to the global section of the config: access to * by * read Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: LDAP Crafted Search Request Access Allowed
On Mon, Oct 27, 2014 at 03:43:03PM -0300, Net Warrior wrote: Based on the the ACL's I posted from my configuration, what else can you recommend to include, tweak or modify? As both Michael and Dieter have said, this is very dependent on your site's requirements and policy. You need to work out what those are. If you can answer these questions, we might be able to help you some more: 1) Should an anonymous user be able to get any data at all? (Ignore the root entry: we are talking about the subtree under dc=domain,dc=com here) 2) What classes of user should have access to the data? Examples might be: LDAP administrator Web applications Desktop addressbook users Webmail users Directory synchronisation processes 3) For each of the above, what data (entries and attributes) do they need? 4) How will the users authenticate to the LDAP service? i.e. Will the user DNs and passwords be configured into the applications, or is the human user expected to supply a username and password each time? Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: LDAP Crafted Search Request Access Allowed
On Tue, Oct 28, 2014 at 11:03:44AM -0300, Net Warrior wrote: 1 - Well, users only authenticate their passwords, nothing else, on the client side to login to the server, so I guess anon logins should not be allowed. So is the LDAP service just used to provide passwd and group databases for Unix-like systems, and not for any other purpose? 2 - I use the Manager account to login to the phplpdapadmin console or apache directory studio. If my guess above is right then you have missed a very important class of LDAP user. Every Unix-like server must access LDAP data. Do your Unix/Linux systems bind to LDAP with specific DNs? (This will be configured in files such as /etc/ldap.conf /etc/nslcd.conf /etc/sssd.conf etc...) 3 - Password and groups and ppolicy 4 - Using pam on the client side, a human is expected to provide username and password which is working along with the ppolicy, expiration time , password lenght and so on. I can provide how's configured if you want. Right, so the account(s) used by the Unix-like systems must be able to search based on username, groupname, numeric UID and numeric GID. Those accounts must also be able to retrieve most attributes from the LDAP entries (though not the password value). I assume you allow users to change their own passwords. How is this handled? Are users allowed to update any other details, or do all changes come to you? Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: LDAP Crafted Search Request Access Allowed
On Tue, Oct 28, 2014 at 01:53:22PM -0300, Net Warrior wrote: So is the LDAP service just used to provide passwd and group databases for Unix-like systems, and not for any other purpose? Yes, only password auth OK. How many systems (approximately) use this? How many users are registered, and how many groups? If my guess above is right then you have missed a very important class of LDAP user. Every Unix-like server must access LDAP data. Do your Unix/Linux systems bind to LDAP with specific DNs? (This will be configured in files such as /etc/ldap.conf /etc/nslcd.conf /etc/sssd.conf etc...) Yes, ldap.conf client config file. base dc=server,dc=com # The distinguished name to bind to the server with. # Optional: default is to bind anonymously. #binddn cn=Manager,dc=example,dc=com I hope you don't really bind with the ROOTDN account! That would expose the most important password in your system to anyone who managed to compromise a single server. I would suggest creating either a single account for all client machines of a given type, or one account per client machine. That way if one client gets compromised you just have to change one password and don't have to rush around fixing every other client config. Please tell us what you decide to do here, as it affects how the ACLs might be written. bind_policy soft idle_timelimit 3600 pam_filter objectClass=posixAccount pam_lookup_policy yes pam_check_host_attr yes pam_password exop nss_base_passwd ou=Users,dc=server,dc=com?one nss_base_shadow ou=Users,dc=server,dc=com?one nss_base_group ou=Groups,dc=server,dc=com?one ssl start_tls #ssl on tls_cacertfile /etc/openldap/certs/cert.pem tls_cacertdir /etc/openldap/certs You should also add: tls_reqcert demand and you may want to consider restricting the connection to high-grade ciphers e.g.: tls_ciphers HIGH:MEDIUM:@STRENGTH I assume you allow users to change their own passwords. How is this handled? Are users allowed to update any other details, or do all changes come to you? yes, they can change their password based on the ppolicy and the pam module, other properties are changed by me, like phone number, photo, address and so on. OK, and the config lines above include 'pam_password exop' so it should use the modern mechanism. I am signing off for the day, but you might like to read this paper bearing in mind what we have discussed: http://www.skills-1st.co.uk/papers/ldap-acls-jan-2009/ I think we are heading for a very simple 'User read-only' policy, but there may be other issues to consider depending on the size of your user-base. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Openldap for proxy AD
On Wed, Nov 20, 2013 at 02:55:43PM -0200, Willy Ramos wrote: Subject: Re: Openldap for proxy AD Have you tried following the examples in the Admin Guide? http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authentication There is a detailed setup and diagnosic guide there which should help you to isolate the problem. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: separate login/password for several services?
On Fri, Sep 27, 2013 at 10:16:43PM +0200, Michael Ströder wrote: Did not follow this thread closely. But one should be aware of ITS#6825 when planning to use slapo-unique for a more complex setup. unique_uri filter reaching beyond its intended target http://www.openldap.org/its/index.cgi?findid=6825 Good point. We started with these ACLs: overlay unique unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SMTP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=IMAP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=POP3) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=XMPP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SSH) so that bug will prevent modifications to the authority entries even though adds will be processed OK. I cannot think of an easy workaround in this case :-( Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: OpenLDAP duplication
On Mon, Sep 30, 2013 at 01:39:03PM +0400, 25Dollar Tech wrote: According to my understanding, LDAP authenticates (binds) with DN (distinguish name) and password. E.g. CN=bob, OU=Users,DC=test,DC=com. So OpenLDAP allows the same CN in a different OU. Yes of course - that is how LDAP and X.500 are designed. Is there any option to prevent it. ? Use the 'unique' overlay: http://www.openldap.org/doc/admin24/overlays.html#Attribute%20Uniqueness Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: separate login/password for several services?
On Fri, Sep 27, 2013 at 01:23:54AM -2100, Zeus Panchenko wrote: overlay unique unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SMTP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=IMAP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=POP3) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=XMPP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SSH) this prevents each uid=X,ou=People,dc=org from having more than one authorizedService=Y offspring ... while the original idea is to let user A to have for the service B, several uid-s but to prevent other users to have the same uids for the corresponding service ... what I mean are multiple attributes uid/userpassword inside the offspring not in the `dn' of the offspring: That can be done - it is just a matter of choosing a naming structure that allows it. dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org uid: john uid: john1 uid: johnN userPassword: qwerty userPassword: qwerty1 userPassword: qwertyN cn: john@xmpp.org sn: xmpp.org description: John Doe XMPP account at xmpp.org uidNumber: 12345 gidNumber: 23456 homeDirectory: /nonexistent loginShell: /sbin/nologin objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: authorizedServiceObject That one won't work, as there is no way to link the individual uid and userPassword values. You need one LDAP entry per uid so either add another layer to the tree or use multi-valued RDNs. The tree version would look like this: dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org dn: uid=john,authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org uid: john userPassword: qwerty dn: uid=john1,authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org uid: john1 userPassword: qwerty1 dn: uid=johnN,authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org uid: johnN userPassword: qwertyN The multi-valued RDNs version like this: dn: uid=john+authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org uid: john userPassword: qwerty dn: uid=john1+authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org uid: john1 userPassword: qwerty1 dn: uid=johnN+authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org uid: johnN userPassword: qwertyN and in this case we need to prevent some other user from having offspring with the same uid ... to prevent for user uid=johandoe,ou=People,dc=org offspring: dn: authorizedService=xmpp.org,uid=johandoe,ou=People,dc=org authorizedService: xmpp.org uid: johan uid: johan1 userPassword: qwerty userPassword: qwerty1 cn: johan@xmpp.org sn: xmpp.org description: Johan Doe XMPP account at xmpp.org uidNumber: 12345 gidNumber: 23456 homeDirectory: /nonexistent loginShell: /sbin/nologin objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: authorizedServiceObject possibility to add another `uid: johnN' which is already used by dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org That should already be covered by the unique overlay setup. Incidentally, you seem to be misusung some fields in the person object: cn: john@xmpp.org sn: xmpp.org If you really don't want to put the real name there you should choose a different objectclass that does not force you to fill in those attributes. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: separate login/password for several services?
On Fri, Sep 27, 2013 at 02:25:24PM +0300, Zeus Panchenko wrote: have I create dedicated object like: dn: authorizedService=YYY,uid=AAA,dc=ZZZ before configuring the service for the user like: dn: uid=XXX,authorizedService=YYY,uid=AAA,dc=ZZZ or the second one will be enough? You have to create the branch points before you can add entries under them. That is why I suggested the alternative where both the service name and the uid are part of the RDN: such multi-valued RDNs are unusual, but it might be a convenient structure in this case. as for the different classes ... I was trying to find it but faced the problem when the parent record, which contains objectclass: posixAccount objectclass: inetOrgPerson objectclass: organizationalPerson objectclass: person objectclass: inetLocalMailRecipient was refusing the child creation until the child belongs to that set of classes :( There must have been some other reason for the error. LDAP servers do not normally restrict what type of entry you can create at a given point in the DIT. The ACLs in force might restrict what you can do, but you have control over those. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: separate login/password for several services?
On Fri, Aug 09, 2013 at 04:17:02PM +0300, Zeus Panchenko wrote: the uniqueness while *creating* the dn ... since for dn-s dn: authorizedService=target-service,uid=target-user1,ou=People,dc=org dn: authorizedService=target-service,uid=target-user2,ou=People,dc=org ... dn: authorizedService=target-service,uid=target-userN,ou=People,dc=org I want to prevent the possibility to create the same uid=john-whatever-format-it-is If you always put the uid in the DN using the structure shown above then it will not be possible to create duplicates. That assumes that you use the same uid in all the subentries of the main user entry... now I do can ldapadd these ldif-s successfully ---[ ldif ] dn: authorizedService=xmpp.org,uid=jdoe,ou=People,dc=org authorizedService: xmpp.org cn: john@xmpp.org sn: xmpp.org description: John Doe XMPP account at xmpp.org uidNumber: 12345 gidNumber: 23456 homeDirectory: /nonexistent loginShell: /sbin/nologin objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: authorizedServiceObject uid: john dn: authorizedService=xmpp.org,uid=jsmith,ou=People,dc=org authorizedService: xmpp.org cn: john.sm...@xmpp.org sn: xmpp.org description: John Smith XMPP account at xmpp.org uidNumber: 12356 gidNumber: 23456 homeDirectory: /nonexistent loginShell: /sbin/nologin objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: authorizedServiceObject uid: john ---[ ldif ] Both those entries have one uid in the entry and a different one in the DN. The one in the DN refers to the parent entry in each case so it is legal but maybe not what you want. It may be enough for you to simply prevent the non-uniqueness. You can do that using the 'unique' overlay: overlay unique unique_uri ldap:///ou=People,dc=org?uid?sub Unfortunately this creates another problem: *every entry* must have a different uid - probably not what you want... It would be possible to write an access-control list using sets to require that the two uids match. This is not quite as simple as there are various cases to consider. Again it may be too restrictive, as then every sub-entry would have to have the same uid as the main entry (though the passwords could still be different). If each 'john' account exists in a distinct identifiable namespace then you could either put the name of the namespace in the account entry or you could use it as part of the LDAP hierachy. The application can then formulate a search that finds the correct entry in one operation. I was thinking to use sn: attribute since it is login dedicated dn: and it is no need in it The data you are putting there is clearly *not* a surname. Don't misuse attributes like this - it will cause trouble later. A more appropriate attribute might be associatedDomain - you will need to add the objectclass 'domainRelatedObject' as well. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: separate login/password for several services?
On Fri, Aug 09, 2013 at 05:53:57PM +0300, Zeus Panchenko wrote: To: Andrew Findlay andrew.find...@skills-1st.co.uk Please keep replies on the list so that they become searchable and everyone can benefit. here is the diagram depicting what I am thinking about while talking :) https://www.dropbox.com/s/212kdpbiug9obkc/org-ldap-diagram-plane.png I dedicate these DN-s for services, so each such DN *can and supposed to* use any (in theory) uid in the entry, the user can ask for Do you reall want every user account on every service to have a different username? (i.e. the user cannot request to be known as 'fred' on both the SMTP service and the IMAP service? in particular, I do not see another way to authenticate users of different domains(for email)/realms(for xmpp) against the same LDAP DB That depends on how you provide the services. If the network address of the services used by domain-A users is different from that used by domain-B users then the server processes will know which domain they are serving. If the same network address is used to serve all domains then you do indeed require the uids to be unique across domains (but you probably do want to let f...@x.y.com use that ID for all services). It may be enough for you to simply prevent the non-uniqueness. You can do that using the 'unique' overlay: mmm ... will not it prevent non-uniqueness only for parent DN-s? while what I'm trying to ask (I'm sorry for muddled up explanation what I mean) about is - uniqueness for the uid *in* the entry ... so, the uniqueness of the attribute `uid' among all DN-s containing authorizedService=target-service You could do that if you are prepared to have one config line for each service. Something like: overlay unique unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SMTP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=IMAP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=POP3) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=XMPP) unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SSH) Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: adding mail objectClass to schema
On Thu, Aug 01, 2013 at 01:57:14PM -0400, Darouichi, Aziz wrote: dn: cn=Google,ou=Group,dc=curry,dc=edu objectclass: groupOfUniqueNames cn: mail: description: uniqueMember: uniqueMember: when I try to add the file I get the following error:adding new entry cn= Google,ou=Group,dc=curry,dc=edu ldap_add: Object class violation (65) additional info: attribute 'mail' not allowed That is correct. The definition of groupOfUniqueNames is: objectclass ( 2.5.6.17 NAME 'groupOfUniqueNames' DESC 'RFC2256: a group of unique names (DN and Unique Identifier)' SUP top STRUCTURAL MUST ( uniqueMember $ cn ) MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) ) 'mail' is not listed as an allowed attribute. If you want to add that attribute then you also need to include a suitable auxiliary object class that permits it. I don't think there is such a class in the standard set, so you will have to create one of your own. That is probably a good thing to do anyway, and you could start with a definition like this: objectclass ( 1.2.826.0.1.3458854.666.1.1 NAME 'curryEduMailObject' DESC 'Aux object class for curry.edu' SUP top AUXILIARY MAY ( mail ) ) Your entry now has two objectclasses: dn: cn=Google,ou=Group,dc=curry,dc=edu objectclass: groupOfUniqueNames objectclass: curryEduMailObject cn: mail: description: uniqueMember: uniqueMember: Ideally you should use an OID based on your own institution's allocation, but that is not critical at this stage. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: separate login/password for several services?
On Thu, Aug 01, 2013 at 10:41:25AM +0300, Zeus Panchenko wrote: I need to set separate credentials for each service I provide (optionally) to my users That seems perverse - most of us work hard to *reduce* the number of different usernames and passwords that each person has to use! I think of something like this: dn: uid=target-user,ou=People,dc=ibs userPassword: ** ... authorizedService: xmpp authorizedService: smtp authorizedService: pop authorizedService: imap authorizedService: mail ... loginSMTP: mail-send-login passwSMTP: xxx loginPOP3: mail-get-login passwPOP3: yyy ... loginXMPP: login-xmpp passwXMPP: zzz You would end up creating two new attributes for each service type, and OpenLDAP would still not check the passwords for you in a useful way. Better method: Create a sub-entry below the user entry for each service. The service-specific entry can use the standard 'uid' and 'userPassword' attributes, and you just need to make sure that each service includes the authorizedService attribute when searching for the entry to authenticate. Something like this: dn: uid=target-user,ou=People,dc=ibs uid: target-user cn: sn: dn: authorizedService=smtp,uid=target-user,ou=People,dc=ibs authorizedService: smtp uid: mail-send-login userPassword: ** dn: authorizedService=pop3,uid=target-user,ou=People,dc=ibs authorizedService: pop3 uid: mail-get-login userPassword: ** Your SMTP server would issue searches of the form: ((uid=USERNAME)(authorizedService=smtp)) Your POP3 server would issue searches of the form: ((uid=USERNAME)(authorizedService=pop3)) Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: olcAccess best practices
On Wed, Jul 31, 2013 at 06:11:02PM +, Jancewicz, Russell wrote: Should I create a single entry per account I want to give access, granting all attributes they would need read/write access to with a particular filter? No - you will end up having to change the ACLs every time you add a user. Or would I be better off grouping access granting to members of the groups and adding individual rules for special edge cases? Much better, but try to avoid those edge cases too! Or are both these ideas off base and something else would be preferred? Currently I am granting access by groups with access to collections of attributes, however as I am discovering that some accounts need access to those attributes with different filters my rules are continually shifting and growing. Try to cut the complexity of ACLs as far as possible. ACLs are effectively programs and they take a lot of testing when they are modified. I always try to turn the day-to-day changes into group-membership changes as then the routine mods are just 'data' rather than 'program'. One approach you might look at is to use two layers of groups: one to categorise users by role (printer admin, user-support, accounts) and one to give access to specific resources (password-writer, home-address-reader, mail-address-reader). You can then make the role groups members of the appropriate resource groups, which is a more understandable way to express policy than typical ACLs. More ideas here: http://www.skills-1st.co.uk/papers/ldap-acls-jan-2009/ Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: SSHA as default password-hash in next password change
On Tue, Jun 04, 2013 at 10:49:27PM -0500, cbul...@gmail.com wrote:
We are already using overlay and it is working perfectly.
Your point about MD5 is great!...but we have some requirements and the
idea is use SSHA-512 for our password.
I read some post from Michael talking about this problem and I know that
there is a contrib module for SSHA-512.
It all depends on what you are protecting against and what you have to
interwork with. The high-profile risk for most organisations is the
theft of large numbers of username-password pairs, so I tend to focus
on mitigating that risk.
For an indication of the relative strengths of various hash schemes, see
Hashcat: http://hashcat.net/oclhashcat-plus/ (table near the bottom of the
page).
On the basis of that table, SSHA-512 will gain you about a factor of
10 protection over SSHA1. A single PC with a mid-range graphics card
can still try about 70,000,000 password guesses per second.
Remember that MD5 and the SHA series were designed to be *fast*.
This is exactly the opposite of what you want when protecting
passwords, so password hash schemes have to use delaying tactics on
top.
If all your LDAP servers will run on Linux, Solaris, or similar OS then you
can stay with $6$ like this:
password-hash {CRYPT}
password-crypt-salt-format $6$%.12s
The result will be about 60,000 times harder to break than SSHA.
The $6$ hash uses SHA512, but does it many times. The effect is to
reduce that single PC's attack rate to nearer 12,000 guesses per
second. If your LDAP database gets compromised or someone steals your
backup tapes then that extra protection could be very valuable.
Andrew
--
---
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/+44 1628 782565 |
---
Re: SSHA as default password-hash in next password change
On Mon, Jun 03, 2013 at 03:54:38PM -0500, cbul...@gmail.com wrote:
We are not using any client..we are just changing the user password from
ssh console.
If you use the passwd command, the LDAP operation used to make the change
will depend on your PAM LDAP implementation. It might be the Password
Modify extended operation (good) or it might be an ordinary LDAP Modify
operation (less good).
We imported our /etc/passwd to openldap and our idea is when the user
gets the next expiration time the new password be in SSHA.
Is it possible?
To catch both cases above you will need to add an overlay to your slapd
config. First set the desired hash in the global section:
password-hash {SSHA}
Then add an overlay on top of the main database section:
overlay ppolicy
ppolicy_default cn=Password Policy,dc=dir,dc=example,dc=org
ppolicy_hash_cleartext
You should also create the password policy entry, something like this:
# Default password policy
# Applies to userPassword (2.5.4.35)
dn: cn=Password Policy,dc=dir,dc=example,dc=org
objectClass: organizationalRole
objectClass: pwdPolicy
cn: Password Policy
description: The default password policy
pwdAttribute: 2.5.4.35
pwdLockout: TRUE
The overall effect will be that passwords that arrive at the LDAP server in
plain text will be hashed using the SSHA scheme. Any passwords that arrived
pre-hashed (e.g. by PAM LDAP) will be stored as-is (it is not possible to
convert from one hash scheme to another).
Why are you changing from MD5 to SSHA? If it is to improve password
security you may be disappointed, depending on which MD5-based hash you
currently use. As the passwords came from an /etc/passwd file it is likely
that they use the $6$ or $2a$ hash schemes. Those are both vastly more
secure than {SSHA} against brute-force attacks. The known weaknesses in the
MD5 algorithm are much less significant than the fact that {SSHA} only runs
the algorithm *once* whereas $6$ and $2a$ are carefully designed to be slow
to calculate.
For an indication of the relative strengths of various hash schemes, see
Hashcat: http://hashcat.net/oclhashcat-plus/ (table near the bottom of the
page).
If all your LDAP servers will run on Linux, Solaris, or similar OS then you
can stay with $6$ like this:
password-hash {CRYPT}
password-crypt-salt-format $6$%.12s
The result will be about 60,000 times harder to break than SSHA.
Andrew
--
---
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/+44 1628 782565 |
---
Re: Substring Indexes on userPassword Attribute
On Tue, Jun 04, 2013 at 08:21:56AM -0500, Dan White wrote: You could replace the objectclasses containing userPassword, homeDirectory, etc, with your own custom defined schema, along with your own userPassword definitions. That would likely require a slapcat, edit, and slapadd of your database, but ultimately gives you more control of your data, and leaves you with portable data. It would probably defeat the object of using LDAP too! As far as I know, OpenLDAP will only authenticate against the userPassword attribute (unless you write an overlay to do something different of course). Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Substring Indexes on userPassword Attribute
On Fri, May 31, 2013 at 10:13:12AM -0700, Tim Gustafson wrote: slapd.conf: line 82: substr index of attribute userPassword disallowed And quite right too! You really don't want to make it any easier for an attacker to search for weak passwords. Why is that? How can I do a search that would tell me which of my users is using an SHA-hashed password? You don't need to modify the Slapd setup for that: just work with an LDIF backup of the data (e.g. from slapcat). Use grep to extract the userPassword attributes. You will then need a script to convert the values from Base-64 encoding to text, and a regular expression to extract the encoding scheme from the front of the text string. That will let you count the number of users for each scheme. (e.g. using sort and uniq). If you really want to know which users use which scheme then replace grep with an LDIF parser and extract both userPassword and uid at the same time. The LDIF parser will take care of the Base-64 for you as well. You should be able to do the whole job in less than 20 lines of Perl or Python. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Substring Indexes on userPassword Attribute
On Mon, Jun 03, 2013 at 09:53:30AM -0700, Tim Gustafson wrote:
At the very least, this ought to be an option. I can see not making a
search index on userPassword by default, but as a system administrator
I ought to be able to make that decision for myself. I don't need a
person who has absolutely no context about my situation telling me
that I can't use my copy of the software to do something I want to do
with my data.
I can sympathise with that, though I would point out that allowing
indexes on userPassword would make an attack through the LDAP
protocol rather easier.
Also, why are there some other things that can't be searched via
substring (like homeDirectory)? What if I want to know which users are
using bash because we're thinking about upgrading it and want to
notify those users? Or what if I want to know which users are using
/usr/local/bin/bash instead of /bin/bash so that I can update the
database to be consistent?
In a word, 'history'. It all comes down to the schema, and the schema
evolved over time without ever really getting cleaned up and
rationalised. Taking userPassword as an example:
attributetype ( 2.5.4.35 NAME 'userPassword'
DESC 'RFC2256/2307: password of user'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
This actually goes right back to X.500(1988). The schema says that
you can do exact matches but no other sort. Worse still, it
completely ducks the character-set encoding issue.
Things like homedir and login shell come from RFC2307 and you get a
similar result:
attributetype ( 1.3.6.1.1.1.1.3 NAME 'homeDirectory'
DESC 'The absolute path to the home directory'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetype ( 1.3.6.1.1.1.1.4 NAME 'loginShell'
DESC 'The path to the login shell'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
Even 2307bis does not give you substring search, though if you make a
case for it the authors might consider adding it...
Having said that, you still might be able to do substring searches on
some of these attributes by using 'matching rule assertion' rather
than 'attribute-value assertion' forms - see RFC4515.
Andrew
--
---
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/+44 1628 782565 |
---
Re: index on attribute in acl filter
On Thu, May 09, 2013 at 02:18:55PM -0400, Al wrote:
I am looking for a way to allow certain support individuals to unlock
ldap accounts that have been locked by too many failed auth attempts
(ppolicy), however I do not want them to be able to unlock accounts
that have been locked for administrative reasons. I was assuming I
could use an ACL like the one below, since we lock an account for
administrative reasons with the same pwdAccountLockedTime value -
{6}to dn.subtree=cn=users,dc=company,dc=com
filter=(!(pwdAccountLockedTime=0101Z)) by
group/groupOfUniqueNames/uniqueMember.exact=cn=user_admins,cn=groups,dc=company,dc=com
write by users read
{7}to dn.subtree=cn=users,dc=company,dc=com
filter=(pwdAccountLockedTime=0101Z) by
group/groupOfUniqueNames/uniqueMember.exact=cn=super_user_admins,cn=groups,dc=company,dc=com
by users read
Those ACIs control general read access - I assume you would
modify them to grant write access to just the
pwdAccountLockedTime attribute. In fact you may need to grant
'manage' access, as this is an operational attribute that is
not usually modified directly.
I know for a search with that filter, an index on pwdAccountLockedTime
would be beneficial, but would it help for an acl filter?
An index is very unlikely to make any difference to the ACL
you propose.
Andrew
--
---
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/+44 1628 782565 |
---
Re: ACL on create questions
[ Keep copying to the openldap-technical@openldap.org list ] On Thu, May 02, 2013 at 02:15:02PM +, Emmanuel Dreyfus wrote: It almost works. My only concern is that it is possible to create an object where LHS of DN is not in object's attributes. Like this: dn: foo=x,o=org objectClass: fooClass foo: y There was some argument about that a few years ago. I am sure that the intention of X.500 was for values in the RDN to be *chosen from* values in the entry. X.501(1988) section 8.1(g) defines an RDN: A set of attribute value assertions, each of which is true, concerning the distinguished values of a particular entry. Unfortunately, somewhere along the line one or more LDAP implementations permitted values in the RDN to be *in addition to* the values in the entry. This was a pain as it was not clear how search filters etc should behave, but some people with loud voices apparently became dependent on it. I remember someone (probably Kurt) saying at one point that the behaviour was wrong but someone had written it into the standards so it had to be supported. However, LDAP is now defined by RFC4512 which says this: 2.3.1. Relative Distinguished Names Each entry is named relative to its immediate superior. This relative name, known as its Relative Distinguished Name (RDN) [X.501], is composed of an unordered set of one or more attribute value assertions (AVA) consisting of an attribute description with zero options and an attribute value. These AVAs are chosen to match attribute values (each a distinguished value) of the entry. I read that as equivalent to the original X.501 definition, so maybe we should now treat the behaviour you see as a bug. Which version of slapd are you using? When I try this on 2.4.35 the extra value from the RDN gets copied into the entry so although the LDIF being loaded is not strictly correct it does result in a conformant entry. What does your entry look like when you read it back? Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Modern Password Hashes in Openldap?
On Tue, Apr 30, 2013 at 08:21:30AM +0200, Michael Ströder wrote:
--On Monday, April 29, 2013 3:28 PM -0700 Chris Hiestand
chiest...@salk.edu
wrote:
Since SSHA-1 is weak these days I'd like to switch to PBKDF2, Bcrypt or
the like with key stretching. Since Openldap does not support relatively
strong hashes, do you guys use SASL to store stronger hashes? If so, what
kind of backend are you using to store hashes?
To be more precise:
One could use the sources in contrib/slapd-modules/passwd/ as a template for
implementing PBKDF2, Bcrypt, etc. schemes. There are no such implementations
yet.
Much easier: use one of the hash schemes supported by the underlying
platform's own crypt library. Most Linux, FreeBSD, OpenBSD, Solaris etc
will allow you to use a range of hash functions by specifying the salt
format string. The more recent hash formats allow you to choose the
number of iterations so that you can tune the algorithm to provide the
desired degree of protection against brute-force attacks.
See man crypt(3) on your platform for details of what is supported.
To enable this in slapd.conf add these lines to the global section:
password-hash {CRYPT}
password-crypt-salt-format $6$%.12s
The salt format here is '$6$' which invokes a SHA512-based hash method
and provides 12 characters (72 bits) of salt. It uses the default 5000
iterations. The table on Hashcat's home page suggests that this is around
50,000 times stronger than the simple SSHA1 hash.
For a slightly stronger hash you might choose bcrypt - introduced by
'$2a$' or '$2y$'. Before doing so you should read the description in
crypt(3) about bugs in early versions relating to 8-bit hashes.
To make sure that passwords presented as plaintext data in the
userPassword attribute get hashed, you should add the Password Policy
overlay:
overlay ppolicy
ppolicy_default cn=Password Policy,dc=dir,dc=example,dc=org
ppolicy_hash_cleartext
... and create a default policy entry something like this:
# Applies to userPassword (2.5.4.35)
dn: cn=Password Policy,dc=dir,dc=example,dc=org
objectClass: organizationalRole
objectClass: pwdPolicy
cn: Password Policy
description: The default password policy
pwdAttribute: 2.5.4.35
pwdLockout: TRUE
BE AWARE that this still only controls passwords set via the LDAP
protocol. If you use slapadd to load your data then the database will get
exactly what is in the ldif file.
Andrew
--
---
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/+44 1628 782565 |
---
Re: LDAP proxy
On Fri, Apr 19, 2013 at 09:49:36AM +, Šerých Jakub wrote: I manage the school network in which we have two separate MS-AD servers (one for teachers and the other for students). We also have mySQL database of our alumni. I would like to connect this three information bases to one virtual LDAP server (for authentication purposes on various LAMP web servers etc.). Is it possible to configure such virtual or proxy server using OpenLDAP? And if yes, could anybody be so kind and redirect me to some how-to resources? That should be possible. You need to decide how you want the three data sources to show up in the LDAP tree presented to the client systems, and you need to consider what happens if the same username (uid in LDAP terms) appears in more than one data-source. I would start by building a simple LDAP proxy in front of one AD and getting that working first (use the LDAP backend or the META backend). Then try putting an rwm overlay on it and changing the name mapping. Once those are working, try a simple SQL backend in isolation. Finally, join all three together in the same server using the relay overlay. Documentation is here: http://www.openldap.org/doc/admin24/ Look in the Backends and Overlays sections in particular. You will also need to search Google and the Faq-O-Matic for examples as some of the documentation is a bit thin. http://www.openldap.org/faq/data/cache/1.html Some things are better explained in the manpages than in the Admin Guide. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: missing entry in slapcat backup
On Wed, Jan 30, 2013 at 04:19:17PM +0100, Meike Stone wrote: Thanks for enlighten me. I've a separate backup server (read only slave), where I can do this. So I'll try to get money from the FC for more RAM to make the test in a ramdisk ^^ You may not need to expand the physical RAM. Most Linux systems these days have a tmpfs mounted on /tmp or on something like /dev/shm - this is a 'virtual ramdisk' which will use RAM and swapspace as appropriate. Its size is fixed at mount time, but can be configured to be larger than the physical RAM if you have enough swapspace to support it. Even when extended into swap, I would expect this to be faster than a normal filesystem as it does not have to take precautions to recover after a crash. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Access control
On Fri, Feb 01, 2013 at 04:56:18PM +, Philip Colmer wrote: I have a followup requirement where I need to be able to restrict read access to the groups as well as write access. I only want the owners of an object to be able to read and write that object. The reason for wanting to do this is to ensure that a user only sees the groups that they can edit when they are using LDAP Account Manager. We have quite a large number of groups and I am trying to head off users complaining that they can't find the group they need to edit. I've been experimenting with the ACLs to try to get it to work but I can only get it to work if the owner is explicitly mentioned, rather than indirectly mentioned as per the member of a group approach. The ACLs so far are: access to dn.one=dc=example,dc=com by users read by * none If your users are also stored in a subtree of dc=example,dc=com then you may need to give anonymous users a bit more access to this node. It depends on how your login process works, in particular the stage that maps from a username to a DN. access to dn.one=ou=groups,dc=example,dc=com by users read by * none OK so far. access to dn.sub=ou=groups,dc=example,dc=com attrs=objectClass,uniqueMember by users read by * none I assume this is to support point (3) below - probably not needed. access to dn.sub=ou=groups,dc=example,dc=com by dnattr=owner write by users none by * none access to dn.sub=ou=groups,dc=example,dc=com by set=this/owner/uniqueMember user write by users none by * none Here you have a problem, as the second clause will never be used. If you want to allow both direct owners and ownership via groups then you should merge these two - something like this: access to dn.sub=ou=groups,dc=example,dc=com by dnattr=owner write by set=this/owner/uniqueMember user write by * none I am always a bit wary of putting both direct and indirect references in the same attribute, just in case some entry that you think is a user ends up with a uniqueMember attribute somehow. (I know that having 'by users none' is redundant but it is there to be explicit) OK - and you can add it to the merged version if you like. The purpose of the ACLs is 1. Allow everyone to see the OU structure in the domain. 2. Allow everyone to see the OUs within the groups OU. It may not do that. Do you want everyone to see all the OUs, or only those that they are 'owner' of? Is there a layer of OUs under ou=groups,dc=example,dc=com with the actual groups further down? If so, you may need to add a clause to give access to the intermediate OUs. 3. The intention here is to grant enough access to the attributes of a group so that slapd can then evaluate the uniqueMember attribute. It isn't entirely clear to me whether slapd needs a rule like this or should be able to evaluate membership etc before it applies acls for the user. Slapd will read whatever it needs for internal use in evaluating ACLs so don't worry about it here. On the other hand, you *do* need to grant adequate (auth) access to *user* entries so that anon can authenticate. 4. Allow directly mentioned owners to write, nothing to everyone else. 5. Allow indirectly mentioned owners to write, nothing to everyone else. With the change given above, that bit should work. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: missing entry in slapcat backup
On Mon, Jan 28, 2013 at 12:15:19PM +0100, Meike Stone wrote: I think, it would be a great thing to test the slapcat file (after dumping it) instantly. Testing backups is always wise... So as reported in http://www.openldap.org/lists/openldap-technical/201301/msg00254.html I tried to do this with a broken backup and the dry-run switch. But slapadd did not report the error. It will work only with a real import. Are there other possibilities, or can be slapadd modified, that this will report such error? Dryrun won't be able to detect missing structural entries: that requires a database. Even an internal list of DNs is not enough, as the actual entries have to be available in order to check things like schema and content rules. To be a valid test you really have to import the data into a server with configuration identical to the production server. If that would take too long then a reasonable compromise might be to import to a server set up to write data as fast as possible. You could reasonably turn off all database-safety functions to do that, or put the database on a ramdisk. Even if you use hdb on the production servers you might consider trying mdb for the backup tests. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
Re: Access control
On Thu, Jan 24, 2013 at 12:22:18PM +, Philip Colmer wrote: What I want/need to be able to do is for LDAP to read the DN of the group that has permission, in the same what that it does with dnattr. I thought that I had read something about this being possible with sets, but slapd.access says that The statement set=pattern is undocumented yet. so I'm not clear if that is the most appropriate way to proceed. Can someone please advise on how this might be accomplished? Sets are indeed the answer. The documentation only exists in the OpenLDAP FAQ-o-matic at present, but you need something like this: access to dn.sub=ou=groups,dc=example,dc=com by set=this/manager/member user write by users read by * none That ACL would give write access to members of any group whose DN is listed in the manager attribute. The basic idea is that this/manager/member produces a set of DNs, user produces a set containing the DN of the bound user, and generates the intersection of the two sets. If the result is a non-empty set then the by clause applies. Andrew -- --- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/+44 1628 782565 | ---
