[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Access being denied.
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.