How do I allow root aka dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external to edit olcDatabase={1}mdb,cn=config. I am trying to configure ldapscripts https://packages.debian.org/jessie/ldapscripts, but the idea of having a password in the clear is just disturbing.
Ldapscripts is in sbin and needs to be ran by someone with root privileges anyways. The easiest way of getting around having a password in the clear would be SASL binding root and mapping it to olcRootDN: when it binds so root can modify the directory tree when it executes ldapscripts.
Am Tue, 2 Aug 2016 00:37:58 -0400 schrieb John Lewis oflameo2@gmail.com:
How do I allow root aka dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external to edit olcDatabase={1}mdb,cn=config. I am trying to configure ldapscripts https://packages.debian.org/jessie/ldapscripts, but the idea of having a password in the clear is just disturbing.
There is no password involved, if handled this correctly. The idea is that posix account of root is bound to uid number 0 and group id number 0. While data transport is done over ldapi (IPC) and a SASL EXTERNAL Mechanism is called, ipc function provides permission information to the operation. This permission id is mapped onto rootdn of cn=config. [...]
-Dieter
On 08/02/2016 05:15 AM, Dieter Klünter wrote:
Am Tue, 2 Aug 2016 00:37:58 -0400 schrieb John Lewis oflameo2@gmail.com:
How do I allow root aka to edit olcDatabase={1}mdb,cn=config. I am trying to configure ldapscripts https://packages.debian.org/jessie/ldapscripts, but the idea of having a password in the clear is just disturbing.
There is no password involved, if handled this correctly. The idea is that posix account of root is bound to uid number 0 and group id number 0. While data transport is done over ldapi (IPC) and a SASL EXTERNAL Mechanism is called, ipc function provides permission information to the operation. This permission id is mapped onto rootdn of cn=config. [...]
-Dieter
If I wanted to map the permissions from dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external to my olcRootDN: which I will call cn=Manager,dc=example,dc=com which is the olcRootDN: for dn: olcDatabase={1}mdb,cn=config, how would I do it?
On 02. aug. 2016 13:15, John Lewis wrote:
If I wanted to map the permissions from dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external to my olcRootDN: which I will call cn=Manager,dc=example,dc=com which is the olcRootDN: for dn: olcDatabase={1}mdb,cn=config, how would I do it?
Set the global directive olcAuthzRegexp (in cn=config) aka authz-regexp (in slapd.conf) to "^gidNumber=0[+]uidNumber=0,cn=peercred,cn=external$" "cn=Manager,dc=example,dc=com"
On 08/02/2016 08:17 AM, Hallvard Breien Furuseth wrote:
On 02. aug. 2016 13:15, John Lewis wrote:
If I wanted to map the permissions from dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external to my olcRootDN: which I will call cn=Manager,dc=example,dc=com which is the olcRootDN: for dn: olcDatabase={1}mdb,cn=config, how would I do it?
Set the global directive olcAuthzRegexp (in cn=config) aka authz-regexp (in slapd.conf) to "^gidNumber=0[+]uidNumber=0,cn=peercred,cn=external$" "cn=Manager,dc=example,dc=com"
Slapd.conf? That is deprecated so I don't use it at all. I use ldapvi or ldbedit instead and connect using cn=config as the base and cn=admin,cn=config as the bind dn.
They both render the directory as a file and run the ldap query behind the scenes.
On 08/02/2016 08:29 AM, John Lewis wrote:
On 08/02/2016 08:17 AM, Hallvard Breien Furuseth wrote:
On 02. aug. 2016 13:15, John Lewis wrote:
If I wanted to map the permissions from dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external to my olcRootDN: which I will call cn=Manager,dc=example,dc=com which is the olcRootDN: for dn: olcDatabase={1}mdb,cn=config, how would I do it?
Set the global directive olcAuthzRegexp (in cn=config) aka authz-regexp (in slapd.conf) to "^gidNumber=0[+]uidNumber=0,cn=peercred,cn=external$" "cn=Manager,dc=example,dc=com"
Slapd.conf? That is deprecated so I don't use it at all. I use ldapvi or ldbedit instead and connect using cn=config as the base and cn=admin,cn=config as the bind dn.
They both render the directory as a file and run the ldap query behind the scenes.
I thought I figured out what you meant and I tried to add olcAuthzRegexp as an attribute but I got this error.
failed to modify olcDatabase={1}mdb,cn=config - LDAP error 65 LDAP_OBJECT_CLASS_VIOLATION - <attribute 'olcAuthzRegexp' not allowed> <>
On 02. aug. 2016 14:45, John Lewis wrote:
On 08/02/2016 08:29 AM, John Lewis wrote:
On 08/02/2016 08:17 AM, Hallvard Breien Furuseth wrote:
(...) Set the global directive olcAuthzRegexp (in cn=config) aka authz-regexp (in slapd.conf) to "^gidNumber=0[+]uidNumber=0,cn=peercred,cn=external$" "cn=Manager,dc=example,dc=com"
(...) failed to modify olcDatabase={1}mdb,cn=config - LDAP error 65 LDAP_OBJECT_CLASS_VIOLATION - <attribute 'olcAuthzRegexp' not allowed> <>
*Global* directive. Set it on the "cn=config" entry. I should have added, maybe olcAuthzRegexp is already set, in which case you can add to it. You can't map the same DN to several different DNs, but you can map different DNs to various DNs - same or different.
On Tue, Aug 02, 2016 at 12:37:58AM -0400, John Lewis wrote:
How do I allow root aka dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external to edit olcDatabase={1}mdb,cn=config.
Besides olcAuthRegex mentioned by other posters, setting up an explicit access control entry for that DN is another option.
If you installed slapd from the Debian archive, the default access rules for the config database include:
# Config db settings dn: olcDatabase=config,cn=config objectClass: olcDatabaseConfig olcDatabase: config # Allow unlimited access to local connection from the local root user olcAccess: to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break
You could grant root-like access to the root user by copying that access line to your mdb database.
On 08/02/2016 11:43 AM, Ryan Tandy wrote:
On Tue, Aug 02, 2016 at 12:37:58AM -0400, John Lewis wrote:
How do I allow root aka dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external to edit olcDatabase={1}mdb,cn=config.
Besides olcAuthRegex mentioned by other posters, setting up an explicit access control entry for that DN is another option.
If you installed slapd from the Debian archive, the default access rules for the config database include:
# Config db settings dn: olcDatabase=config,cn=config objectClass: olcDatabaseConfig olcDatabase: config # Allow unlimited access to local connection from the local root user olcAccess: to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break
You could grant root-like access to the root user by copying that access line to your mdb database.
Root can read, but it can't write.
dictator@soothsayer:~$ sudo ldapadd -H ldapi:/// -f add_ldap-connect1.ldif -Y EXTERNAL SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=ldap-connect1,ou=People,dc=d,dc=oflameo,dc=com" ldap_add: Insufficient access (50) additional info: no write access to parent
I am guessing that it has something to do with the order of the ACLs.
olcAccess: {0}to dn.base="" by * read olcAccess: {1}to * by * read olcAccess: {2}to attrs=userPassword,shadowLastChange by self write by anonymou s auth by * none olcAccess: {3}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by * break
On 08/05/2016 07:42 AM, John Lewis wrote:
On 08/02/2016 11:43 AM, Ryan Tandy wrote:
On Tue, Aug 02, 2016 at 12:37:58AM -0400, John Lewis wrote:
How do I allow root aka dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external to edit olcDatabase={1}mdb,cn=config.
Besides olcAuthRegex mentioned by other posters, setting up an explicit access control entry for that DN is another option.
If you installed slapd from the Debian archive, the default access rules for the config database include:
# Config db settings dn: olcDatabase=config,cn=config objectClass: olcDatabaseConfig olcDatabase: config # Allow unlimited access to local connection from the local root user olcAccess: to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break
You could grant root-like access to the root user by copying that access line to your mdb database.
Root can read, but it can't write.
dictator@soothsayer:~$ sudo ldapadd -H ldapi:/// -f add_ldap-connect1.ldif -Y EXTERNAL SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=ldap-connect1,ou=People,dc=d,dc=oflameo,dc=com" ldap_add: Insufficient access (50) additional info: no write access to parent
I am guessing that it has something to do with the order of the ACLs.
olcAccess: {0}to dn.base="" by * read olcAccess: {1}to * by * read olcAccess: {2}to attrs=userPassword,shadowLastChange by self write by anonymou s auth by * none olcAccess: {3}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by * break
I reorganized the olcAccess and now root can write to the directory.
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by * read olcAccess: {3}to attrs=userPassword,shadowLastChange by self write by anonymous auth by * none
Today at 8:10am, John Lewis wrote:
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by * read olcAccess: {3}to attrs=userPassword,shadowLastChange by self write by anonymous auth by * none
And the world can read your passwords...
Order *is* important. First match wins. At the very least you need to put #2 as the very last rule.
On 08/05/2016 09:08 AM, Frank Swasey wrote:
Today at 8:10am, John Lewis wrote:
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by * read olcAccess: {3}to attrs=userPassword,shadowLastChange by self write by anonymous auth by * none
And the world can read your passwords...
Order *is* important. First match wins. At the very least you need to put #2 as the very last rule.
How is this?
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break olcAccess: {1}to dn.base="" by * read olcAccess: {2}to attrs=userPassword,shadowLastChange by self write by anonymous auth by * none olcAccess: {3}to * by * read
You said to do that at the very least. What else do you think I should do?
John Lewis wrote:
How is this?
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break olcAccess: {1}to dn.base="" by * read olcAccess: {2}to attrs=userPassword,shadowLastChange by self write by anonymous auth by * none olcAccess: {3}to * by * read
Slightly better. But the user (self) can still circumvent shadowUser's legacy password expiry by setting attribute 'shadowLastChange'. Well, that's an obsolete feature anyway and shadowAccount should not be used nowadays.
In general when crafting ACLs you should have a test plan or even better automated testing which should also cover the cases which should *not* be possible. Starting with writing down access control requirements before is highly recommended too.
Ciao, Michael.
openldap-technical@openldap.org
-
Dieter Klünter -
Frank Swasey -
Hallvard Breien Furuseth -
John Lewis -
Michael Ströder -
Ryan Tandy