Back with a further clarification and trying to solve a problem for our programmers.
ldapsearch -x -H ldapi:/// -s base -b '' namingContext "*" + -D $ROOTDN -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: namingContext * + #
# dn: objectClass: top objectClass: OpenLDAProotDSE structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: cn=accesslog namingContexts: dc=example,dc=com monitorContext: cn=Monitor supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 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 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: PLAIN supportedSASLMechanisms: LOGIN supportedSASLMechanisms: EXTERNAL entryDN: subschemaSubentry: cn=Subschema
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
So our programmers want me to filter out 'namingContexts: cn=accesslog' for them (please don't ask).
# cat naming_context.ldif dn: olcDatabase={-1}frontend,cn=config changetype: modify add: olcAccess olcAccess: {0}to dn.exact="" attrs=namingContext val/distinguishedNameMatch="cn=accesslog transitional" by * none
ldapmodify -H ldapi:/// -Y EXTERNAL -f naming_context.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={-1}frontend,cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: <olcAccess> handler exited with 1
Anyone want to hit me with a clue stick so I can hide the 'cn=accesslog' database from my programmers so they don't have to rewrite code?
Oh - and I put in just a single value in the ldif...
dn: olcDatabase={-1}frontend,cn=config changetype: modify add: olcAccess olcAccess: {0}to dn.exact="" attrs=namingContext val/distinguishedNameMatch="cn=accesslog" by * none
but the result is the same
Craig White System Administrator O 623-201-8179 M 602-377-9752
[cid:image001.png@01CF86FE.42D51630]
SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032
From: openldap-technical [mailto:openldap-technical-bounces@openldap.org] On Behalf Of Craig White Sent: Monday, May 18, 2015 3:59 PM To: openldap-technical@openldap.org Subject: hiding a naming context
Back with a further clarification and trying to solve a problem for our programmers.
ldapsearch -x -H ldapi:/// -s base -b '' namingContext "*" + -D $ROOTDN -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: namingContext * + #
# dn: objectClass: top objectClass: OpenLDAProotDSE structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: cn=accesslog namingContexts: dc=example,dc=com monitorContext: cn=Monitor supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 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 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: PLAIN supportedSASLMechanisms: LOGIN supportedSASLMechanisms: EXTERNAL entryDN: subschemaSubentry: cn=Subschema
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
So our programmers want me to filter out 'namingContexts: cn=accesslog' for them (please don't ask).
# cat naming_context.ldif dn: olcDatabase={-1}frontend,cn=config changetype: modify add: olcAccess olcAccess: {0}to dn.exact="" attrs=namingContext val/distinguishedNameMatch="cn=accesslog transitional" by * none
ldapmodify -H ldapi:/// -Y EXTERNAL -f naming_context.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={-1}frontend,cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: <olcAccess> handler exited with 1
Anyone want to hit me with a clue stick so I can hide the 'cn=accesslog' database from my programmers so they don't have to rewrite code?
-----Original Message----- From: Michael Ströder [mailto:michael@stroeder.com] Sent: Tuesday, May 19, 2015 1:04 AM To: Craig White; openldap-technical@openldap.org Subject: Re: hiding a naming context
Craig White wrote:
Oh - and I put in just a single value in the ldif...
dn: olcDatabase={-1}frontend,cn=config changetype: modify add: olcAccess olcAccess: {0}to dn.exact="" attrs=namingContext
s/namingContext/namingContexts/
---- I see said the blind man - worked - thanks.
Now to determine if that actually hurts anything that I am doing otherwise.
Thanks
Craig
Am Dienstag, 19. Mai 2015 17:22 CEST, Craig White CWhite@skytouchtechnology.com schrieb:
-----Original Message----- From: Michael Ströder [mailto:michael@stroeder.com] Sent: Tuesday, May 19, 2015 1:04 AM To: Craig White; openldap-technical@openldap.org Subject: Re: hiding a naming context
Craig White wrote:
Oh - and I put in just a single value in the ldif...
dn: olcDatabase={-1}frontend,cn=config changetype: modify add: olcAccess olcAccess: {0}to dn.exact="" attrs=namingContext
s/namingContext/namingContexts/
I see said the blind man - worked - thanks.
Now to determine if that actually hurts anything that I am doing otherwise.
Hmm - maybe I miss the obvious, but wasn't your initial goal "So our programmers want me to filter out ‘namingContexts: cn=accesslog’ for them (please don’t ask)"? Won't the above ACL block _all_ namingContexts attributes?
Cheers, Ralf Mattes
Craig
Ralf Mattes wrote:
Am Dienstag, 19. Mai 2015 17:22 CEST, Craig White CWhite@skytouchtechnology.com schrieb: Michael Ströder wrote:
Craig White wrote:
Oh - and I put in just a single value in the ldif...
dn: olcDatabase={-1}frontend,cn=config changetype: modify add: olcAccess olcAccess: {0}to dn.exact="" attrs=namingContext
s/namingContext/namingContexts/
I see said the blind man - worked - thanks.
Now to determine if that actually hurts anything that I am doing otherwise.
Hmm - maybe I miss the obvious, but wasn't your initial goal "So our programmers want me to filter out ‘namingContexts: cn=accesslog’ for them (please don’t ask)"? Won't the above ACL block _all_ namingContexts attributes?
See Craig's original posting with the whole attr-value ACL. I've shortened it to point out the actual error.
Ciao, Michael.
-----Original Message----- From: Ralf Mattes [mailto:rm@mh-freiburg.de] Sent: Tuesday, May 19, 2015 8:46 AM To: Craig White Cc: openldap-technical@openldap.org Subject: RE: hiding a naming context
Am Dienstag, 19. Mai 2015 17:22 CEST, Craig White CWhite@skytouchtechnology.com schrieb:
-----Original Message----- From: Michael Ströder [mailto:michael@stroeder.com] Sent: Tuesday, May 19, 2015 1:04 AM To: Craig White; openldap-technical@openldap.org Subject: Re: hiding a naming context
Craig White wrote:
Oh - and I put in just a single value in the ldif...
dn: olcDatabase={-1}frontend,cn=config changetype: modify add: olcAccess olcAccess: {0}to dn.exact="" attrs=namingContext
s/namingContext/namingContexts/
I see said the blind man - worked - thanks.
Now to determine if that actually hurts anything that I am doing otherwise.
Hmm - maybe I miss the obvious, but wasn't your initial goal "So our programmers want me to filter out ‘namingContexts: cn=accesslog’ for them (please don’t ask)"? Won't the above ACL block _all_ namingContexts attributes? ---- -----Original Message----- From: Ralf Mattes [mailto:rm@mh-freiburg.de] Sent: Tuesday, May 19, 2015 8:46 AM To: Craig White Cc: openldap-technical@openldap.org Subject: RE: hiding a naming context
Am Dienstag, 19. Mai 2015 17:22 CEST, Craig White CWhite@skytouchtechnology.com schrieb:
-----Original Message----- From: Michael Ströder [mailto:michael@stroeder.com] Sent: Tuesday, May 19, 2015 1:04 AM To: Craig White; openldap-technical@openldap.org Subject: Re: hiding a naming context
Craig White wrote:
Oh - and I put in just a single value in the ldif...
dn: olcDatabase={-1}frontend,cn=config changetype: modify add: olcAccess olcAccess: {0}to dn.exact="" attrs=namingContext
s/namingContext/namingContexts/
I see said the blind man - worked - thanks.
Now to determine if that actually hurts anything that I am doing otherwise.
Hmm - maybe I miss the obvious, but wasn't your initial goal "So our programmers want me to filter out ‘namingContexts: cn=accesslog’ for them (please don’t ask)"? Won't the above ACL block _all_ namingContexts attributes?
Cheers, Ralf Mattes ---- I think Michael clipped an extra line
dn: olcDatabase={-1}frontend,cn=config changetype: modify add: olcAccess olcAccess: {0}to dn.exact="" attrs=namingContexts val/distinguishedNameMatch="cn=accesslog" by * none
but to your point - that indeed seems to be what happened - nothing returned in naming contexts at all...
# ldapsearch -x -H ldapi:/// -s base -b '' namingContext "*" + -D cn=admin,dc=domain,dc=com -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: namingContext * + #
# search result search: 2 result: 0 Success
# numResponses: 1
We have had issues with outlook365 for a week now but I am leaving this message mostly unchanged. Is it possible to have an ACL that blocks ONLY one naming context and not everything?
--On Tuesday, May 19, 2015 4:22 PM +0000 Craig White CWhite@skytouchtechnology.com wrote:
I see said the blind man - worked - thanks.
Now to determine if that actually hurts anything that I am doing otherwise.
These sorts of hacks to work around bad programming on the client side are really not the right way to go. Just to note. ;)
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
--On Monday, May 18, 2015 11:59 PM +0000 Craig White CWhite@skytouchtechnology.com wrote:
Back with a further clarification and trying to solve a problem for our programmers.
Anyone want to hit me with a clue stick so I can hide the 'cn=accesslog' database from my programmers so they don't have to rewrite code?
Hire competent programmers.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Craig White -
Michael Ströder -
Quanah Gibson-Mount -
Ralf Mattes