[Date Prev][Date Next] [Chronological] [Thread] [Top]
Fw: Access being denied.

To: openldap-technical@openldap.org
Subject: Fw: Access being denied.
From: espeake@oreillyauto.com
Date: Tue, 24 Sep 2013 06:31:35 -0500

Eric Speake
Web Systems Administrator
O'Reilly Auto Parts
----- Forwarded by Eric Speake/OReilly on 09/24/2013 06:31 AM -----

From:	Eric Speake/OReilly
To:	Jason Brandt <jbrandt@fsmail.bradley.edu>
Cc:	openlda-technical@openldap.org
Date:	09/24/2013 06:16 AM
Subject:	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/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


Jason,

Thanks for the layout and I will take this to my bosses.  I might have to
group the servers because we have several servers that access the out LDAP
servers and by IP address would be a little cumbersome to manage.  We use
somewhere in the range of 140 different applications on our internal
network and accessed by our stores across the country.  so we use different
accounts to do different types of access depending on the application so we
don't use just one admin account and this works on the old LDAP server
running 2.4.21  But when I try to replicate the ACL's it has, nothing
works. so for the time being I have simplified as recommended by this
community and then I will work on tightening down the reigns.  Right now I
need to figure out why my ldapadmin account doesn't have write permissions
in accordance with my ACL on the servers.  Is it as simple as a syntax
issue.

The other issue I mentioned is starting to get a little annoying in the
fact that I cannot seem to modify my config.  The changes don't happen but
the modify timestamp changes.  I can deal with that issue later.  Right now
I need to get this user working.

Thanks,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts.

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.




--
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.
Prev by Date: Re: another CSN too old N-WAY master
Next by Date: Re: another CSN too old N-WAY master
Index(es):
- Chronological
- Thread