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, <[email protected]> wrote: > > > > From: Jason Brandt <[email protected]> > To: [email protected] > Cc: "[email protected]" > <[email protected]> > 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, <[email protected]> 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
