[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
{SOLVED] Error 18: Solaris 10 Native LDAP-Client
- To: Ralf Haferkamp <rhafer@suse.de>
- Subject: {SOLVED] Error 18: Solaris 10 Native LDAP-Client
- From: Benjamin Griese <der.darude@gmail.com>
- Date: Wed, 3 Nov 2010 16:03:28 +0100
- Cc: James Bagley Jr <james.bagley@state.or.us>, openldap-technical@openldap.org
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=cmM1KskF9GdE+9cgTlTmBjPp+lywbtcDPsHmxlVPoag=; b=BCfSpMROB6JpVu7QYtDIU9yUidnb5DBZuWoOgKZ/macPrD+DcB9kVs3+v5u+JytW3V 0PtDaS7cfeP8LTfEJ43MNhe8w9IgdJ61nGp2Ufb5qvw3fPE/3rW3tjk3v8F3RWdkalaA mNiCeoXByS3Ln2DSlm7L4n6kfDuYqXYDgNVQ8=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=miAJj+V45ZjGUBLdxYB+DgcYpMyxFQaf/tL5LGDQ5PgcpfvPxrCC/pbiCVVhAwrKff SicvTzDSHx1Odoii0R85Yb70wZ6ICE6jNq8R9g5Ptdu8lnmYk9jzn4Y00HWeSL2c5+Z/ /D6mRrhDK4Z+9gA6O8bBf2SQEm2dFpyRXEWI8=
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 <rhafer@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