I know this has to be super simple in what I am missing. My ldapadmin account cannot write to the database due to insufficient privileges.. This is the ACL part of the ldif file. Version 2.4.31 and this is from olcDatabase={1}hdb.ldif
olcAccess: {0}to attrs=userPassword by dn="uid=admin,dc=oreillyauto,dc=com" wr ite by anonymous auth by self write by * none olcAccess: {1}to dn.subtree="" by * read olcAccess: {2}to * by dn="uid=admin,dc=oreillyauto,dc=com" write by dn="uid=ld apadmin,ou=System,dc=oreillyauto,dc=com" write by * read
olcAccess: {2} for ldap admin actually be 'dn.base="uid=ldapadmin,ou-System, dc=<domain>,dc=com" write'?
Thanks Eric Speake Web Systems Administrator O'Reilly Auto Parts
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
I hope this doesn't confuse you too much... First off... Your admin account will be dn="cn=admin,dc=oreillyauto,dc=com", if you are talking about the default admin account. You also want manage instead of write. I would also recommend securing your admin account with access lists, only allowing access from specific manager IP addresses. In order to restrict the cn=admin account as I do below, you have to set the userPassword attribute for the admin account, and blank the olcRootPW.
set admin password: dn: cn=admin,dc=bradley,dc=edu changeType: modify add: userPassword userPassword: {SSHA}<passwordhash>
blank old olcRootPW
dn: olcDatabase={1}hdb,cn=config changetype: modify delete: olcRootPW
This allows use of the normal authentication process and will look at your access lists. Otherwise, it will always bypass access lists and use the olcRootPW to authenticate.
Here's how I handle access restrictions, which I would suggest you evaluate. This is a positive security model as well (meaning the default action is deny), which I highly recommend (ie no one can access any field, unless it's specifically defined). The downside to the positive security model is that it's less flexible, you have to whitelist any new attributes you wish users to access, but it provides you with the best security. Another note in this, is that my user accounts are all shadowAccounts, and setting shadowInactive to 1 disables the account. (handled by the 3rd section with password fields).
Here is my access list in a template form:
dn: olcDatabase={1}hdb,cn=config changetype: modify replace: olcAccess # limit access to directory manager to local host only and specific manager ip's olcAccess: to dn.base="cn=admin,dc=,dc=" by peername.ip=127.0.0.1 auth by sockurl=ldapi:/// auth by peername.ip=<manager IP> auth by users none by anonymous none #Allow admin users full access to all attrs #Allow OpenLDAP2 Sync User read access to all #Everyone else, continue olcAccess: to * by peername.ip=172.16.0.0%255.255.0.0 dn="uid=adminuser,dc=,dc=" manage by peername.ip=<secondary ldap server ip> dn="uid=syncuser,ou=Service_Logins,dc=,dc=" read by peername.ip=<third ldap server ip> dn="uid=syncuser,ou=Service_Logins,dc=,dc=" read by * break #Handle password fields, for all possible entities. No further processing for these attributes olcAccess: to attrs=userPassword,shadowLastChange filter=(&(objectClass=shadowAccount)(!(shadowInactive=1))) by self =w by sockurl=ldapi:/// auth by peername.ip=172.16.0.0%255.255.0.0 auth by peername.ip=127.0.0.1 group.exact="cn=localadmingroup,dc=,dc=" manage by group.exact="cn=admingroup,dc=,dc=" write by * none #Specific processing for an Account #Everyone else, continue olcAccess: to attrs=attr1,attr2 by dn="uid=account1,ou=Service_Logins,dc=,dc=" read by * break #Specific processing for a Group #Everyone else, continue olcAccess: to attrs=attr3,attr4 by group.exact="cn=group1,out=Group,dc=,dc=" manage by * break #Handle SELF writable fields #Everyone else, continue olcAccess: to attrs=loginShell,mailRoutingAddress,additionalattrs by self write by * break #Handle more restrictive fields #Stop processing on match olcAccess: to attrs=audio,attr5,attr6,attr7 filter=(&(matchTrue=1)(objectClass=Person)) by * none #Handle Anonymous Allowed fields #Stop Processing on Match olcAccess: to attrs=attr8,attr9,attr10 by * read #Handle User Allowed Fields #Stop Processing on Match olcAccess: to dn.subtree="dc=,dc=" attrs=audio by users read #Hide additional superuser accounts in directory olcAccess: to attrs=entry filter=(|(ou=Service_Logins)(uid=logins)) by * none #Allow access to specific objectclasses olcAccess: to filter=(|(objectClass=nisDomainObject)(objectClass=nisNetGroup)(objectClass=posixGroup)(objectClass=groupOfUniqueNames)(objectClass=organizationalUnit)) by * read #Allow access to directory entries. Required to query directory when using default deny policy olcAccess: to dn.subtree="dc=,dc=" attrs=entry,objectClass by * read #Default Deny olcAccess: to * by * none
On Mon, Sep 23, 2013 at 12:08 PM, espeake@oreillyauto.com wrote:
I know this has to be super simple in what I am missing. My ldapadmin account cannot write to the database due to insufficient privileges.. This is the ACL part of the ldif file. Version 2.4.31 and this is from olcDatabase={1}hdb.ldif
olcAccess: {0}to attrs=userPassword by dn="uid=admin,dc=oreillyauto,dc=com" wr ite by anonymous auth by self write by * none olcAccess: {1}to dn.subtree="" by * read olcAccess: {2}to * by dn="uid=admin,dc=oreillyauto,dc=com" write by dn="uid=ld apadmin,ou=System,dc=oreillyauto,dc=com" write by * read
olcAccess: {2} for ldap admin actually be 'dn.base="uid=ldapadmin,ou-System, dc=<domain>,dc=com" write'?
Thanks Eric Speake Web Systems Administrator O'Reilly Auto Parts
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
From: Jason Brandt jbrandt@fsmail.bradley.edu To: espeake@oreillyauto.com Cc: "openldap-technical@OpenLDAP.org" openldap-technical@openldap.org Date: 09/23/2013 03:26 PM Subject: Re: Access being denied.
I hope this doesn't confuse you too much... First off... Your admin account will be dn="cn=admin,dc=oreillyauto,dc=com", if you are talking about the default admin account. You also want manage instead of write. I would also recommend securing your admin account with access lists, only allowing access from specific manager IP addresses. In order to restrict the cn=admin account as I do below, you have to set the userPassword attribute for the admin account, and blank the olcRootPW.
set admin password: dn: cn=admin,dc=bradley,dc=edu changeType: modify add: userPassword userPassword: {SSHA}<passwordhash>
blank old olcRootPW
dn: olcDatabase={1}hdb,cn=config changetype: modify delete: olcRootPW
This allows use of the normal authentication process and will look at your access lists. Otherwise, it will always bypass access lists and use the olcRootPW to authenticate.
Here's how I handle access restrictions, which I would suggest you evaluate. This is a positive security model as well (meaning the default action is deny), which I highly recommend (ie no one can access any field, unless it's specifically defined). The downside to the positive security model is that it's less flexible, you have to whitelist any new attributes you wish users to access, but it provides you with the best security. Another note in this, is that my user accounts are all shadowAccounts, and setting shadowInactive to 1 disables the account. (handled by the 3rd section with password fields).
Here is my access list in a template form:
dn: olcDatabase={1}hdb,cn=config changetype: modify replace: olcAccess # limit access to directory manager to local host only and specific manager ip's olcAccess: to dn.base="cn=admin,dc=,dc=" by peername.ip=127.0.0.1 auth by sockurl=ldapi:/// auth by peername.ip=<manager IP> auth by users none by anonymous none #Allow admin users full access to all attrs #Allow OpenLDAP2 Sync User read access to all #Everyone else, continue olcAccess: to * by peername.ip=172.16.0.0%255.255.0.0 dn="uid=adminuser,dc=,dc=" manage by peername.ip=<secondary ldap server ip> dn="uid=syncuser,ou=Service_Logins,dc=,dc=" read by peername.ip=<third ldap server ip> dn="uid=syncuser,ou=Service_Logins,dc=,dc=" read by * break #Handle password fields, for all possible entities. No further processing for these attributes olcAccess: to attrs=userPassword,shadowLastChange filter= (&(objectClass=shadowAccount)(!(shadowInactive=1))) by self =w by sockurl=ldapi:/// auth by peername.ip=172.16.0.0%255.255.0.0 auth by peername.ip=127.0.0.1 group.exact="cn=localadmingroup,dc=,dc=" manage by group.exact="cn=admingroup,dc=,dc=" write by * none #Specific processing for an Account #Everyone else, continue olcAccess: to attrs=attr1,attr2 by dn="uid=account1,ou=Service_Logins,dc=,dc=" read by * break #Specific processing for a Group #Everyone else, continue olcAccess: to attrs=attr3,attr4 by group.exact="cn=group1,out=Group,dc=,dc=" manage by * break #Handle SELF writable fields #Everyone else, continue olcAccess: to attrs=loginShell,mailRoutingAddress,additionalattrs by self write by * break #Handle more restrictive fields #Stop processing on match olcAccess: to attrs=audio,attr5,attr6,attr7 filter=(&(matchTrue=1)(objectClass=Person)) by * none #Handle Anonymous Allowed fields #Stop Processing on Match olcAccess: to attrs=attr8,attr9,attr10 by * read #Handle User Allowed Fields #Stop Processing on Match olcAccess: to dn.subtree="dc=,dc=" attrs=audio by users read #Hide additional superuser accounts in directory olcAccess: to attrs=entry filter=(|(ou=Service_Logins)(uid=logins)) by * none #Allow access to specific objectclasses olcAccess: to filter=(| (objectClass=nisDomainObject)(objectClass=nisNetGroup)(objectClass=posixGroup)(objectClass=groupOfUniqueNames)(objectClass=organizationalUnit)) by * read #Allow access to directory entries. Required to query directory when using default deny policy olcAccess: to dn.subtree="dc=,dc=" attrs=entry,objectClass by * read #Default Deny olcAccess: to * by * none
On Mon, Sep 23, 2013 at 12:08 PM, espeake@oreillyauto.com wrote:
I know this has to be super simple in what I am missing. My ldapadmin account cannot write to the database due to insufficient privileges.. This is the ACL part of the ldif file. Version 2.4.31 and this is from olcDatabase={1}hdb.ldif
olcAccess: {0}to attrs=userPassword by dn="uid=admin,dc=oreillyauto,dc=com" wr ite by anonymous auth by self write by * none olcAccess: {1}to dn.subtree="" by * read olcAccess: {2}to * by dn="uid=admin,dc=oreillyauto,dc=com" write by dn="uid=ld apadmin,ou=System,dc=oreillyauto,dc=com" write by * read
olcAccess: {2} for ldap admin actually be 'dn.base="uid=ldapadmin,ou-System, dc=<domain>,dc=com" write'?
Thanks Eric Speake Web Systems Administrator O'Reilly Auto Parts
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
OK. I tried removing the olcRootPW as suggested with the following ldif file
dn: olcDatabase={1}hdb,cn=config changetype: modify
delete: olcRootPW
The password is still there and the modify time stamp shows the time I tried and the user that made the change. But it is still there. I did use the admin user to make the change but I have been having the same issue with other changes I have tried to make as well.
Thanks, Eric Speake Web Systems Administrator O'Reilly Auto Parts
-- Jason K. Brandt Systems Administrator Bradley University (309) 677-2958 -- This message has been scanned for viruses and dangerous content, and is believed to be clean. Message id: A1B06600D64.A7776
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
Are you using the default admin account?
As far as the replication, I have not tried replicating. I only have 2 ldap servers running currently (a primary and a slave), so I just manually apply the ACL's to both servers when there is a change.
I'm not sure why your config changes are not being pushed in. Have you gone detailed with debugging mode, etc, to see if any errors are being logged? It seems to me that this is the source of most of your problems. I would try and track down the cause of that issue first.
On Tue, Sep 24, 2013 at 9:18 AM, espeake@oreillyauto.com wrote:
From: Jason Brandt jbrandt@fsmail.bradley.edu To: espeake@oreillyauto.com Cc: "openldap-technical@OpenLDAP.org" openldap-technical@openldap.org Date: 09/23/2013 03:26 PM Subject: Re: Access being denied.
I hope this doesn't confuse you too much... First off... Your admin account will be dn="cn=admin,dc=oreillyauto,dc=com", if you are talking about the default admin account. You also want manage instead of write. I would also recommend securing your admin account with access lists, only allowing access from specific manager IP addresses. In order to restrict the cn=admin account as I do below, you have to set the userPassword attribute for the admin account, and blank the olcRootPW.
set admin password: dn: cn=admin,dc=bradley,dc=edu changeType: modify add: userPassword userPassword: {SSHA}<passwordhash>
blank old olcRootPW
dn: olcDatabase={1}hdb,cn=config changetype: modify delete: olcRootPW
This allows use of the normal authentication process and will look at your access lists. Otherwise, it will always bypass access lists and use the olcRootPW to authenticate.
Here's how I handle access restrictions, which I would suggest you evaluate. This is a positive security model as well (meaning the default action is deny), which I highly recommend (ie no one can access any field, unless it's specifically defined). The downside to the positive security model is that it's less flexible, you have to whitelist any new attributes you wish users to access, but it provides you with the best security. Another note in this, is that my user accounts are all shadowAccounts, and setting shadowInactive to 1 disables the account. (handled by the 3rd section with password fields).
Here is my access list in a template form:
dn: olcDatabase={1}hdb,cn=config changetype: modify replace: olcAccess # limit access to directory manager to local host only and specific manager ip's olcAccess: to dn.base="cn=admin,dc=,dc=" by peername.ip=127.0.0.1 auth by sockurl=ldapi:/// auth by peername.ip=<manager IP> auth by users none by anonymous none #Allow admin users full access to all attrs #Allow OpenLDAP2 Sync User read access to all #Everyone else, continue olcAccess: to * by peername.ip=172.16.0.0%255.255.0.0 dn="uid=adminuser,dc=,dc=" manage by peername.ip=<secondary ldap server ip> dn="uid=syncuser,ou=Service_Logins,dc=,dc=" read by peername.ip=<third ldap server ip> dn="uid=syncuser,ou=Service_Logins,dc=,dc=" read by * break #Handle password fields, for all possible entities. No further processing for these attributes olcAccess: to attrs=userPassword,shadowLastChange filter= (&(objectClass=shadowAccount)(!(shadowInactive=1))) by self =w by sockurl=ldapi:/// auth by peername.ip=172.16.0.0%255.255.0.0 auth by peername.ip=127.0.0.1 group.exact="cn=localadmingroup,dc=,dc=" manage by group.exact="cn=admingroup,dc=,dc=" write by * none #Specific processing for an Account #Everyone else, continue olcAccess: to attrs=attr1,attr2 by dn="uid=account1,ou=Service_Logins,dc=,dc=" read by * break #Specific processing for a Group #Everyone else, continue olcAccess: to attrs=attr3,attr4 by group.exact="cn=group1,out=Group,dc=,dc=" manage by * break #Handle SELF writable fields #Everyone else, continue olcAccess: to attrs=loginShell,mailRoutingAddress,additionalattrs by self write by * break #Handle more restrictive fields #Stop processing on match olcAccess: to attrs=audio,attr5,attr6,attr7 filter=(&(matchTrue=1)(objectClass=Person)) by * none #Handle Anonymous Allowed fields #Stop Processing on Match olcAccess: to attrs=attr8,attr9,attr10 by * read #Handle User Allowed Fields #Stop Processing on Match olcAccess: to dn.subtree="dc=,dc=" attrs=audio by users read #Hide additional superuser accounts in directory olcAccess: to attrs=entry filter=(|(ou=Service_Logins)(uid=logins)) by * none #Allow access to specific objectclasses olcAccess: to filter=(|
(objectClass=nisDomainObject)(objectClass=nisNetGroup)(objectClass=posixGroup)(objectClass=groupOfUniqueNames)(objectClass=organizationalUnit)) by * read #Allow access to directory entries. Required to query directory when using default deny policy olcAccess: to dn.subtree="dc=,dc=" attrs=entry,objectClass by * read #Default Deny olcAccess: to * by * none
On Mon, Sep 23, 2013 at 12:08 PM, espeake@oreillyauto.com wrote:
I know this has to be super simple in what I am missing. My ldapadmin account cannot write to the database due to insufficient privileges.. This is the ACL part of the ldif file. Version 2.4.31 and this is from olcDatabase={1}hdb.ldif
olcAccess: {0}to attrs=userPassword by dn="uid=admin,dc=oreillyauto,dc=com" wr ite by anonymous auth by self write by * none olcAccess: {1}to dn.subtree="" by * read olcAccess: {2}to * by dn="uid=admin,dc=oreillyauto,dc=com" write by dn="uid=ld apadmin,ou=System,dc=oreillyauto,dc=com" write by * read
olcAccess: {2} for ldap admin actually be 'dn.base="uid=ldapadmin,ou-System, dc=<domain>,dc=com" write'?
Thanks Eric Speake Web Systems Administrator O'Reilly Auto Parts
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
OK. I tried removing the olcRootPW as suggested with the following ldif file
dn: olcDatabase={1}hdb,cn=config changetype: modify
delete: olcRootPW
The password is still there and the modify time stamp shows the time I tried and the user that made the change. But it is still there. I did use the admin user to make the change but I have been having the same issue with other changes I have tried to make as well.
Thanks, Eric Speake Web Systems Administrator O'Reilly Auto Parts
-- Jason K. Brandt Systems Administrator Bradley University (309) 677-2958 -- This message has been scanned for viruses and dangerous content, and is believed to be clean. Message id: A1B06600D64.A7776
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
From: Jason Brandt jbrandt@fsmail.bradley.edu To: espeake@oreillyauto.com Cc: "openldap-technical@OpenLDAP.org" openldap-technical@openldap.org Date: 09/24/2013 09:37 AM Subject: Re: Access being denied.
Are you using the default admin account?
As far as the replication, I have not tried replicating. I only have 2 ldap servers running currently (a primary and a slave), so I just manually apply the ACL's to both servers when there is a change.
I'm not sure why your config changes are not being pushed in. Have you gone detailed with debugging mode, etc, to see if any errors are being logged? It seems to me that this is the source of most of your problems. I would try and track down the cause of that issue first.
On Tue, Sep 24, 2013 at 9:18 AM, espeake@oreillyauto.com wrote:
From: Jason Brandt jbrandt@fsmail.bradley.edu To: espeake@oreillyauto.com Cc: "openldap-technical@OpenLDAP.org" openldap-technical@openldap.org Date: 09/23/2013 03:26 PM Subject: Re: Access being denied.
I hope this doesn't confuse you too much... First off... Your admin account will be dn="cn=admin,dc=oreillyauto,dc=com", if you are talking about the default admin account. You also want manage instead of write. I would also recommend securing your admin account with access lists, only allowing access from specific manager IP addresses. In order to restrict the cn=admin account as I do below, you have to set the userPassword attribute for the admin account, and blank the olcRootPW.
set admin password: dn: cn=admin,dc=bradley,dc=edu changeType: modify add: userPassword userPassword: {SSHA}<passwordhash>
blank old olcRootPW
dn: olcDatabase={1}hdb,cn=config changetype: modify delete: olcRootPW
This allows use of the normal authentication process and will look at your access lists. Otherwise, it will always bypass access lists and use the olcRootPW to authenticate.
Here's how I handle access restrictions, which I would suggest you evaluate. This is a positive security model as well (meaning the default action is deny), which I highly recommend (ie no one can access any field, unless it's specifically defined). The downside to the positive security model is that it's less flexible, you have to whitelist any new attributes you wish users to access, but it provides you with the best security. Another note in this, is that my user accounts are all shadowAccounts, and setting shadowInactive to 1 disables the account. (handled by the 3rd section with password fields).
Here is my access list in a template form:
dn: olcDatabase={1}hdb,cn=config changetype: modify replace: olcAccess # limit access to directory manager to local host only and specific manager ip's olcAccess: to dn.base="cn=admin,dc=,dc=" by peername.ip=127.0.0.1 auth by sockurl=ldapi:/// auth by peername.ip=<manager IP> auth by users none by anonymous none #Allow admin users full access to all attrs #Allow OpenLDAP2 Sync User read access to all #Everyone else, continue olcAccess: to * by peername.ip=172.16.0.0%255.255.0.0 dn="uid=adminuser,dc=,dc=" manage by peername.ip=<secondary ldap server ip> dn="uid=syncuser,ou=Service_Logins,dc=,dc=" read by peername.ip=<third ldap server ip> dn="uid=syncuser,ou=Service_Logins,dc=,dc=" read by * break #Handle password fields, for all possible entities. No further processing for these attributes olcAccess: to attrs=userPassword,shadowLastChange filter= (&(objectClass=shadowAccount)(!(shadowInactive=1))) by self =w by sockurl=ldapi:/// auth by peername.ip=172.16.0.0%255.255.0.0 auth by peername.ip=127.0.0.1 group.exact="cn=localadmingroup,dc=,dc=" manage by group.exact="cn=admingroup,dc=,dc=" write by * none #Specific processing for an Account #Everyone else, continue olcAccess: to attrs=attr1,attr2 by dn="uid=account1,ou=Service_Logins,dc=,dc=" read by * break #Specific processing for a Group #Everyone else, continue olcAccess: to attrs=attr3,attr4 by group.exact="cn=group1,out=Group,dc=,dc=" manage by * break #Handle SELF writable fields #Everyone else, continue olcAccess: to attrs=loginShell,mailRoutingAddress,additionalattrs by self write by * break #Handle more restrictive fields #Stop processing on match olcAccess: to attrs=audio,attr5,attr6,attr7 filter=(&(matchTrue=1)(objectClass=Person)) by * none #Handle Anonymous Allowed fields #Stop Processing on Match olcAccess: to attrs=attr8,attr9,attr10 by * read #Handle User Allowed Fields #Stop Processing on Match olcAccess: to dn.subtree="dc=,dc=" attrs=audio by users read #Hide additional superuser accounts in directory olcAccess: to attrs=entry filter=(|(ou=Service_Logins)(uid=logins)) by * none #Allow access to specific objectclasses olcAccess: to filter=(| (objectClass=nisDomainObject)(objectClass=nisNetGroup)(objectClass=posixGroup)(objectClass=groupOfUniqueNames)(objectClass=organizationalUnit))
by * read #Allow access to directory entries. Required to query directory when using default deny policy olcAccess: to dn.subtree="dc=,dc=" attrs=entry,objectClass by * read #Default Deny olcAccess: to * by * none
On Mon, Sep 23, 2013 at 12:08 PM, espeake@oreillyauto.com wrote:
I know this has to be super simple in what I am missing. My ldapadmin account cannot write to the database due to insufficient privileges.. This is the ACL part of the ldif file. Version 2.4.31 and this is from olcDatabase={1}hdb.ldif
olcAccess: {0}to attrs=userPassword by dn="uid=admin,dc=oreillyauto,dc=com" wr ite by anonymous auth by self write by * none olcAccess: {1}to dn.subtree="" by * read olcAccess: {2}to * by dn="uid=admin,dc=oreillyauto,dc=com" write by dn="uid=ld apadmin,ou=System,dc=oreillyauto,dc=com" write by * read
olcAccess: {2} for ldap admin actually be 'dn.base="uid=ldapadmin,ou-System, dc=<domain>,dc=com" write'?
Thanks Eric Speake Web Systems Administrator O'Reilly Auto Parts
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
OK. I tried removing the olcRootPW as suggested with the following ldif file
dn: olcDatabase={1}hdb,cn=config changetype: modify
delete: olcRootPW
The password is still there and the modify time stamp shows the time I tried and the user that made the change. But it is still there. I did use the admin user to make the change but I have been having the same issue with other changes I have tried to make as well.
Thanks, Eric Speake Web Systems Administrator O'Reilly Auto Parts
-- Jason K. Brandt Systems Administrator Bradley University (309) 677-2958 -- This message has been scanned for viruses and dangerous content, and is believed to be clean. Message id: A1B06600D64.A7776
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
-- Jason K. Brandt Systems Administrator Bradley University (309) 677-2958 -- This message has been scanned for viruses and dangerous content, and is believed to be clean. Message id: 80B3D600DE5.A6C66 I have tried looking at better logging and I have to "break the rules" right now to get change my logging since the ldapmodify isn't working. I am using the admon account and replication is working great. A change made to users is instantaneous on the other nodes of my n-way multi-master setup. And when I can get a config change to got through it is replicated to the other nodes just as quickly.
Our current stand alone server is version 2.4.21 and below are the ACL.cong and the olcAccess from olcDatabase={1}hdb.ldif files. This works exactly the way we want it to work. We are upgrading for high availability and the use of the n-way multi-master. WHen I tried using the olcAccess listed here the readOnlyUser that our apps use to read the password attribute would not work so I scaled back to where I am now and having the issue with ldapadmin account.
acl.conf
#O'Reilly LDAP Access Controls
access to dn.subtree="dc=<domain>,dc=com" by group/groupOfUniqueNames/uniqueMember="cn=System Administrators,ou=Groups,dc=<domain>,dc=com" write by group/groupOfUniqueNames/uniqueMember="cn=LDAP Admin,ou=Groups,dc=<domain>,dc=com" write by * none break
access to attrs=userPassword by group/groupOfUniqueNames/uniqueMember="cn=Authenticate,ou=Groups,dc=<domain>,dc=com" read by anonymous auth by self write
access to attrs=uid by anonymous read by users read
access to attrs=ou,employeeNumber by users read
#access to * # by group/groupOfUniqueNames/uniqueMember="cn=Authenticate,ou=Groups,dc=<domain>,dc=com" none # by users none break
access to dn.subtree="ou=System,dc=<domain>,dc=com" by dn.subtree="ou=Users,dc=<domain>,dc=com" none by users read
access to dn.children="ou=Groups,dc=<domain>,dc=com" by dnattr=owner write by dnattr=uniqueMember read by * none
access to dn.children="ou=Users,dc=<domain>,dc=com" by self read by group/groupOfUniqueNames/uniqueMember="cn=Authenticate,ou=Groups,dc=<domain>,dc=com" read by * none
access to * by self read by users read
olcDatabase={1}hdb.ldif
olcAccess:{0}to * by dn.base="uid=syncrepl,ou=System,dc=<domain>,dc=com" read by dn.base="uid=readOnlyUser,ou=System,dc=<domain>,dc=com" read by dn.base="uid=ldapAdmin,ou=System,dc=<domain>,dc=com" write by dn.base="uid=newUserAdmin,ou=System,dc=<domain>,dc=com" write by dn.base="uid=passwordAdmin,ou=System,dc=<domain>,dc=com" write by * break
olcAccess: {1}to dn.subtree="dc=<domain>,dc=com" by group/groupOfUniqueNames/uniqueMember="cn=System Administrators,ou=Groups,dc=<domain>,dc=com" write by group/groupOfUniqueNames/uniqueMember="cn=LDAP Admin,ou=Groups,dc=<domain>,dc=com" write by * none break
olcAccess: {2}to attrs=userPassword by group/groupOfUniqueNames/uniqueMember="cn=Authenticate,ou=Groups,dc=<domain>,dc=com" write by anonymous auth by self write
olcAccess: {3}to attrs=uid by anonymous read by users read
olcAccess: {4}to attrs=ou,employeeNumber by users read
olcAccess: {5}to dn.subtree="ou=System,dc=<domain>,dc=com" by dn.subtree="ou=Users,dc=<domain>,dc=com" none by users read
olcAccess: {6}to dn.children="ou=Groups,dc=<domain>,dc=com" by dnattr=owner write by dnattr=uniqueMember read by * none
olcAccess: {7}to dn.children="ou=Users,dc=<domain>,dc=com" by self read by group/groupOfUniqueNames/uniqueMember="cn=Authenticate,ou=Groups,dc=<domain>,dc=com" read by * none
olcAccess: {8}to * by self read by users read
I will "break the RUles for the logging and to remove the olcRootPW to see how it works.
Thanks, Eric
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
openldap-technical@openldap.org
-
espeake＠oreillyauto.com -
Jason Brandt