ACL and SSF
Hi,
I forced encryption with olcSecurity but some of our applications do not support
ldaps etc.
Now I disabled globally the security and wanted to do it with ACLs to force all
clients
with encryption except for the ip addresses from those application servers.
For this I thought it would work to add the first ACL line like this:
{0}to * by ssf=256 auth by peername.ip=172.16.122.210 auth
{1}
{2}...
But this doesn't seem to work
Can somebody tell me if there is an error in reasoning or how to solve this
approach?
/thx,chris
smime.p7s
Description: S/MIME cryptographic signature
Re: Error 18: Solaris 10 Native LDAP-Client
Am Mittwoch 03 November 2010, 09:52:26 schrieb Benjamin Griese:
Hello Ralf,
[..]
In the meantime I set the ACL, but unfortunatly it didn't help solving
the problem, you may take a look at my example:
DN: olcDatabase={1}hdb,cn=config
olcAccess: {0}to attrs=userPassword,shadowLastChange by
dn=cn=ldapadm,dc=example,dc=de write by
dn=cn=proxyuser,ou=system,ou=people,dc=example,dc=de read by
anonymous auth by self write by * none
olcAccess: {1} to dn.base= attrs=supportedControl
val/objectIdentifierMatch=1.2.840.113556.1.4.473 by * none
olcAccess: {2} to dn.base= attrs=supportedControl
val/objectIdentifierMatch=2.16.840.1.113730.3.4.9 by * none
olcAccess: {3}to dn.base= by * read
olcAccess: {4}to * by dn=cn=ldapadm,dc=example,dc=de write by * read
If I remember right {4} is not opening up the access when it is
explicitly denied in the ACLs {1} {2}, am I right?
Yes, you are right.
But I'm not sure if this is the right place for this kind of ACL,
cn=config instead should be wrong too I guess.
It has to be in the global ACL, i.e. you have to add it to
olcDatabase={-1}frontend,cn=config.
Bye, Benjamin.
[..]
Ralf
--
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
Re: Syncprov checkpoint and sessionlog with cn=config
Quoting Quanah Gibson-Mount qua...@zimbra.com:
I do it via ldapmodify:
dn: olcOverlay=syncprov,olcDatabase={3}hdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckpoint: 20 10
olcSpSessionlog: 500
Thanks, Quanah. Just a bit more Googling and I figured this one out
myself, but these configuration attributes are not well documented
yet, at least not for cn=config. They're not yet included in the
slapo-syncprov man page and (correct me if I'm wrong) the online
documentation doesn't seem to mention them either.
Cheers,
Jaap
Re: syncrepl proxy problem - consumer gets cleared
Sebastian Hofmann schrieb: Sorry, I am using openldap version 2.4.11 on Debian Lenny. I see this version is outdated - I will try a more recent version and see what will happen. Using openldap version 2.4.23 from Debian Squeeze, the problem does not occur anymore. Sebastian
Syncrepl filtering
Hi, I would like to control what gets replicated to my ldap slaves. How would I specify what I don't want to be replicated? Is this even possible or do I have to create a filter that finds everything that I want to send down? Thanks, -- Bram Cymet Software Developer Canadian Bank Note Co. Ltd. Cell: 613-608-9752
{SOLVED] Error 18: Solaris 10 Native LDAP-Client
Hello Ralf,
thank you very much for your help! :)
In the first place it didn't work and I was sure you have tested the
functionality, so I checked what I may have configured
differently/wrong.
So I checked my list of supportedControls which are presented to the clients:
ldapsearch -x -b -s base supportedControl
before:
supportedControl: 1.3.6.1.4.1.4203.1.9.1.1
supportedControl: 2.16.840.1.113730.3.4.9
supportedControl: 1.2.840.113556.1.4.473
supportedControl: 1.3.6.1.4.1.4203.666.5.16
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 1.3.6.1.4.1.4203.1.10.1
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.2.826.0.1.3344810.2.3
supportedControl: 1.3.6.1.1.13.2
supportedControl: 1.3.6.1.1.13.1
supportedControl: 1.3.6.1.1.12
This shows the list of supportedControls and the denied Controls were
still visible.
To make it work I had to put
olcAccess: {1}to dn.base= by * read
further down to
olcAccess: {3}to dn.base= by * read
below the two denied Controls.
after:
supportedControl: 1.3.6.1.4.1.4203.1.9.1.1
supportedControl: 1.3.6.1.4.1.4203.666.5.16
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 1.3.6.1.4.1.4203.1.10.1
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.2.826.0.1.3344810.2.3
supportedControl: 1.3.6.1.1.13.2
supportedControl: 1.3.6.1.1.13.1
supportedControl: 1.3.6.1.1.12
After that the supportedControls weren't visible anymore when
requesting the list.
Finally, my working frontend:
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to dn.base=cn=subschema by * read
olcAccess: {1} to dn.base= attrs=supportedControl val/objectIdentifierMatc
h=1.2.840.113556.1.4.473 by * none
olcAccess: {2} to dn.base= attrs=supportedControl val/objectIdentifierMatc
h=2.16.840.1.113730.3.4.9 by * none
olcAccess: {3}to dn.base= by * read
olcAccess: {4}to attrs=userPassword,userPKCS12 by self write by * auth
olcAccess: {5}to attrs=shadowLastChange by self write by * read
olcAccess: {6}to * by * read
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 0
olcMonitoring: FALSE
olcReadOnly: FALSE
olcSchemaDN: cn=Subschema
olcSyncUseSubentry: FALSE
Now requesting passwd/group/sudoers/etc with the Solaris 10 native
client works like a charm, to me its like less is more. :)
Thanks to all of you who tried to help and fix the problem, especially
Ralf and Dieter.
Have a nice day, Benjamin.
On Wed, Nov 3, 2010 at 12:07, Ralf Haferkamp rha...@suse.de wrote:
Am Mittwoch 03 November 2010, 09:52:26 schrieb Benjamin Griese:
Hello Ralf,
[..]
In the meantime I set the ACL, but unfortunatly it didn't help solving
the problem, you may take a look at my example:
DN: olcDatabase={1}hdb,cn=config
olcAccess: {0}to attrs=userPassword,shadowLastChange by
dn=cn=ldapadm,dc=example,dc=de write by
dn=cn=proxyuser,ou=system,ou=people,dc=example,dc=de read by
anonymous auth by self write by * none
olcAccess: {1} to dn.base= attrs=supportedControl
val/objectIdentifierMatch=1.2.840.113556.1.4.473 by * none
olcAccess: {2} to dn.base= attrs=supportedControl
val/objectIdentifierMatch=2.16.840.1.113730.3.4.9 by * none
olcAccess: {3}to dn.base= by * read
olcAccess: {4}to * by dn=cn=ldapadm,dc=example,dc=de write by * read
If I remember right {4} is not opening up the access when it is
explicitly denied in the ACLs {1} {2}, am I right?
Yes, you are right.
But I'm not sure if this is the right place for this kind of ACL,
cn=config instead should be wrong too I guess.
It has to be in the global ACL, i.e. you have to add it to
olcDatabase={-1}frontend,cn=config.
Bye, Benjamin.
[..]
Ralf
--
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
--
To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To
be is to do -- Sartre | Do be do be do -- Sinatra
ACL permission issue
Hi everyone, I'm facing an ACL problem for a long time, and I got to the point that I'm out of ideas. The problem is related to write in a specific branch of DIT. My DIT has the following hierachy dc=spi,dc=net - c=cl --ou=users ---ou=regular ---ou=admin The ACL should allow the users under the admin subtree to write in the regular subtree (admin and regular users model). SO, I have the following ACL includes in slapd.conf: include /etc/ldap/acls/acl.conf.default include /etc/ldap/acls/acl.conf The ACL files have the following lines: # /etc/ldap/acls/acl.conf.default # The userPassword by default can be changed # by the entry owning it if they are authenticated. # Others should not be able to see it, except the # admin entry below # These access lines apply to database #1 only access to attrs=userPassword,shadowLastChange by dn=cn=admin,dc=spi,dc=net write by anonymous auth by self write by * none # Ensure read access to the base for things like # supportedSASLMechanisms. Without this you may # have problems with SASL not knowing what # mechanisms are available and the like. # Note that this is covered by the 'access to *' # ACL below too but if you change that as people # are wont to do you'll still need this if you # want SASL (and possible other things) to work # happily. access to dn.base= by * read # The admin dn has full write access, everyone else # can read everything. access to * by dn=cn=admin,dc=spi,dc=net write by * read # /etc/ldap/acls/acl.conf access to dn.children=ou=regular,ou=users,c=cl,dc=spi,dc=net attrs=children by dn.sub=ou=admins,ou=users,c=cl,dc=spi,dc=net manage by * read So, I created an user under the admin subtree with the following DN: uid=cl-admin,ou=admins,ou=users,c=cl,dc=spi,dc=net To test, I'm trying to add an user with the following LDIF file: # Teste description: Test dn: uid=test,ou=regular,ou=users,c=cl,dc=spi,dc=net objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: spi # Customized class cn: Teste sn: teste givenName: Teste uid: teste url: http://mysite.com mail: t...@mysite.com l: City TimeZone: GMT-4 area: Gov st: State organization: Organization o: SPI preferredLanguage: en-US However, when I try to add the user (ldapadd -x -D uid=cl-admin,ou=admins,ou=usuarios,c=cl,dc=spi,dc=net -W -f /tmp/test.ldif I get the following error: ldap_add: Insufficient access (50) additional info: no write access to parent The debug output log for ACL's show me the following sequence of information: Nov 3 12:00:47 nodo108 slapd[16629]: hdb_referrals: tag=104 target=uid=test,ou=regular,ou=users,c=cl,dc=spi,dc=net matched=ou=regular,ou=users,c=cl,dc=spi,dc=net Nov 3 12:00:47 nodo108 slapd[16629]: == hdb_add: uid=test,ou=regular,ou=users,c=cl,dc=spi,dc=net Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_required entry (uid=test,ou=regular,ou=users,c=cl,dc=spi,dc=net), objectClass spi Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type objectClass Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type cn Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type sn Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type givenName Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type uid Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type url Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type mail Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type l Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type timeZone Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type area Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type st Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type organization Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type o Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type preferredLanguage Nov 3 12:00:47 nodo108 slapd[16629]: oc_check_allowed type structuralObjectClass Nov 3 12:00:47 nodo108 slapd[16629]: slap_queue_csn: queing 0xb6603a32 20101103140047.629760Z#00#000#00 Nov 3 12:00:47 nodo108 slapd[16629]: bdb_dn2entry(uid=test,ou=regular,ou=users,c=cl,dc=spi,dc=net) Nov 3 12:00:47 nodo108 slapd[16629]: = hdb_dn2id(uid=test,ou=regular,ou=users,c=cl,dc=spi,dc=net) Nov 3 12:00:47 nodo108 slapd[16629]: = hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30990) Nov 3 12:00:47 nodo108 slapd[16629]: = access_allowed: add access to ou=regular,ou=users,c=cl,dc=spi,dc=net children requested Nov 3 12:00:47 nodo108 slapd[16629]: = dn: [1] ou=regular,ou=users,c=cl,dc=spi,dc=net Nov 3 12:00:47 nodo108 slapd[16629]: = dn: [3] Nov 3 12:00:47 nodo108 slapd[16629]: = acl_get: [4] attr children Nov 3 12:00:47 nodo108 slapd[16629]: = acl_mask: access to entry ou=regular,ou=users,c=cl,dc=spi,dc=net, attr children requested Nov 3 12:00:47 nodo108 slapd[16629]: = acl_mask: to all values by
Re: Syncprov checkpoint and sessionlog with cn=config
Quoting Howard Chu h...@symas.com: Jaap Winius wrote: .. but these configuration attributes are not well documented yet, at least not for cn=config. They're not yet included in the slapo-syncprov man page and (correct me if I'm wrong) the online documentation doesn't seem to mention them either. They are simply LDAP schema elements. Their definitions are always present in the directory itself. Okay, at least there's that, but if not in man slapo-syncprov, then I was kind of hoping/expecting that this information would be included in Chapter 18 (Replication) of the online documentation. That page already mentions the slapd.conf versions of these directives, but not the ones for cn=config. They could at least be included in one of the cn=config examples there. % ldapsearch -x -H ldap://:9011 -D cn=config -W -b cn=schema,cn=config -s base | grep -A 2 OLcfgOv..:1 Very handy! Thanks, Jaap
Re: unable to perform authenticated binds
sorry for the frustration all... removing the leading space in front
of rootpw did the trick :)
the directory is now populating, however I cannot understand why it is
choking on this entry
# pam_ldap, Services, acadaca.net
dn: cn=pam_ldap,ou=Services,dc=acadaca,dc=net
cn: pam_ldap
objectClass: top
objectClass: inetOrgPerson
sn: PAM
userPassword:: {SSHA}secret
AFAIK I have ALL the scemas I need to import this entry yet ldapadd chokes
[r...@ldap openldap]# ldapadd -h ldap -x -D
cn=Manager,dc=acadaca,dc=net -w secret -f /home/tim/acadaca2.ldif
ldapadd: invalid format (line 6) entry:
cn=pam_ldap,ou=Services,dc=acadaca,dc=net
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/misc.schema
inlcude /etc/openldap/schema/sudoers.schema
I am sorry to ask for help again.. this sucks
On Wed, Nov 3, 2010 at 12:20 PM, Quanah Gibson-Mount qua...@zimbra.com wrote:
--On Tuesday, November 02, 2010 7:59 PM -0700 Chris Jacobs
chris.jac...@apollogrp.edu wrote:
If you're not calling me out via thanks so much for the exceedingly
useful insight then feel free to skip the rest of this.
I didn't think he was calling you out, myself. ;) Just noting that things
are documented, and people who don't take the time to read the official
project documentation (which happens a lot, unfortunately) don't deserve
sympathy on it. We get a lot of people who spend their time reading
documents from other sources such as Zytrax, which contain completely wrong
information, and then come here to talk about how bad the documentation is.
It gets frustrating.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
--
Here's my RSA Public key:
gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9
Share and enjoy!!
Re: unable to perform authenticated binds
--On Wednesday, November 03, 2010 6:09 PM -0400 Tim Dunphy bluethu...@gmail.com wrote: holy crap!! it was the extra colon that killed it! found it, fixed it.. man oh man sorry for the intrusion! Yeah, :: on userPassword means it is base-64 encoded already, and clearly that bit of LDIF was not base-64 encoded. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: Syncprov checkpoint and sessionlog with cn=config
Jaap Winius wrote: Quoting Howard Chuh...@symas.com: Jaap Winius wrote: .. but these configuration attributes are not well documented yet, at least not for cn=config. They're not yet included in the slapo-syncprov man page and (correct me if I'm wrong) the online documentation doesn't seem to mention them either. They are simply LDAP schema elements. Their definitions are always present in the directory itself. Okay, at least there's that, but if not in man slapo-syncprov, then I was kind of hoping/expecting that this information would be included in Chapter 18 (Replication) of the online documentation. That page already mentions the slapd.conf versions of these directives, but not the ones for cn=config. They could at least be included in one of the cn=config examples there. You're welcome to submit a patch for the docs. As lead developer on the Project I focus on working on the things that would be difficult for anyone else to do. For stuff like this where the information is already available, it's up to the rest of the community to fill in. % ldapsearch -x -H ldap://:9011 -D cn=config -W -b cn=schema,cn=config -s base | grep -A 2 OLcfgOv..:1 People who understand LDAP don't need to be reminded of things like this. They already understand that LDAP-based configuration means that everything is already part of the LDAP schema, and LDAP schema is self-describing so no external document is absolutely required. (Conversely, people who grumble that LDAP-based config is too complicated and a bad idea simply don't understand LDAP...) Very handy! Thanks, Jaap -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: unable to perform authenticated binds
Quanah Gibson-Mount wrote: --On Wednesday, November 03, 2010 6:09 PM -0400 Tim Dunphy bluethu...@gmail.com wrote: holy crap!! it was the extra colon that killed it! found it, fixed it.. man oh man sorry for the intrusion! Yeah, :: on userPassword means it is base-64 encoded already, and clearly that bit of LDIF was not base-64 encoded. ;) And again, stuff like this is clearly documented in the ldif(5) manpage... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
