[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Error 18: Solaris 10 Native LDAP-Client
Hello there,
a short update on my problem for the ppl who care. :)
A colleague of mine could reproduce the situation with the same
version of OpenLDAP 2.4.23 (from the OpenSUSE repo) and Solaris 10,
but there was no problem with an older version of OpenLDAP 2.4.12
(default in sles11 w/o sp1) and said he had no problems getting
listings of users and groups with ldaplist on Solaris 10.
Thats the only problem I have currently on my version of OpenLDAP
2.4.20 (downgraded due to fiddling areount to a "supported" version
from the sles11sp1 repo).
Everything else like loging in, using sudoers, having pwdPolicy and so
was and is working fine with 2.4.20/2.4.23.
I now think there may be a regression somewhere between 2.4.12 and
2.4.20 regarding sssvlv or valsort?!
While I'm writing this I'm installing sles11 with the lower version of
OpenLDAP 2.4.12 on a virtual machine to reproduce atleast the
difference of these versions.
Because this is going to be a production server, my boss is heading
for a support contract with Novell, so I have to use the versions from
the repository. :(
I was not able to find a suitable ticket in the ITS from the past that
could have been related to the problem (to stupid to use this thing?
:)).
Bye, Benjamin.
PS:
Here are some examples what's working and what's not, no matter if
overlays sssvlv or valsort are configured or not:
root@exampleclient # ldaplist -lv passwd testuser1
+++ database=passwd
+++ filter=(&(objectclass=posixaccount)(uid=testuser1))
+++ template for merging SSD filter=(&(%s)(uid=testuser1))
dn: uid=testuser1,ou=people,dc=example,dc=de
loginShell: /bin/bash
sn: testuser1
objectClass: top
objectClass: posixAccount
objectClass: inetOrgPerson
gidNumber: 1000
mail: somewhere@somehow
telephoneNumber:
uidNumber: 1001
gecos: name name desc
cn: testuser1
description: Systemadministrator Unix
homeDirectory: /export/home/testuser1
uid: testuser1
root@exampleclient # ldaplist -lv passwd
+++ database=passwd
+++ filter=objectclass=posixaccount
+++ template for merging SSD filter=%s
ldaplist: Object not found (LDAP ERROR (18): Inappropriate matching.)
root@exampleclient # ldaplist -lv group admin
+++ database=group
+++ filter=(&(objectclass=posixgroup)(cn=admin))
+++ template for merging SSD filter=(&(%s)(cn=admin))
dn: cn=admin,ou=groups,dc=example,dc=de
gidNumber: 1000
objectClass: posixGroup
objectClass: top
objectClass: labeledURIObject
objectClass: groupOfURLs
cn: admin
labeledURI:
ldap:///ou=people,dc=example,dc=de?uid?sub?(objectClass=posixAccount)
memberUid: testuser1
memberUid: testuser2
...
root@exampleclient # ldaplist -lv group
+++ database=group
+++ filter=objectclass=posixgroup
+++ template for merging SSD filter=%s
ldaplist: Object not found (LDAP ERROR (18): Inappropriate matching.)
On Mon, Oct 18, 2010 at 16:00, Benjamin Griese <der.darude@gmail.com> wrote:
> Update: the serverSort thing was a false-positive this morning, I
> guess the client was still caching.
> ...
> Oct 18 15:52:23 examplehost slapd[24946]: conn=9373 op=168 SEARCH
> RESULT tag=101 err=18 nentries=0 text=serverSort control: No ordering
> rule
> Oct 18 15:52:23 examplehost slapd[24946]: conn=9373 op=168 do_search:
> get_ctrls failed
> Oct 18 15:52:52 examplehost slapd[24946]: conn=10575 fd=28 ACCEPT from
> IP=10.0.0.1:35464 (IP=0.0.0.0:389)
> Oct 18 15:52:52 examplehost slapd[24946]: conn=10575 op=0 BIND
> dn="cn=proxyuser,ou=system,ou=people,dc=example,dc=de" method=128
> Oct 18 15:52:52 examplehost slapd[24946]: => bdb_entry_get: found
> entry: "cn=proxyuser,ou=system,ou=people,dc=example,dc=de"
> Oct 18 15:52:52 examplehost slapd[24946]: => bdb_entry_get: found
> entry: "cn=default,ou=pwdpolicy,dc=example,dc=de"
> Oct 18 15:52:52 examplehost slapd[24946]: => access_allowed: result
> not in cache (userPassword)
> Oct 18 15:52:52 examplehost slapd[24946]: => access_allowed: auth
> access to "cn=proxyuser,ou=system,ou=people,dc=example,dc=de"
> "userPassword" requested
> Oct 18 15:52:52 examplehost slapd[24946]: => acl_get: [1] attr userPassword
> Oct 18 15:52:52 examplehost slapd[24946]: => acl_mask: access to entry
> "cn=proxyuser,ou=system,ou=people,dc=example,dc=de", attr
> "userPassword" requested
> Oct 18 15:52:52 examplehost slapd[24946]: => acl_mask: to value by "", (=0)
> Oct 18 15:52:52 examplehost slapd[24946]: <= check a_dn_pat:
> cn=ldapadm,dc=example,dc=de
> Oct 18 15:52:52 examplehost slapd[24946]: <= check a_dn_pat:
> cn=proxyuser,ou=system,ou=people,dc=example,dc=de
> Oct 18 15:52:52 examplehost slapd[24946]: <= check a_dn_pat: anonymous
> Oct 18 15:52:52 examplehost slapd[24946]: <= acl_mask: [3] applying
> auth(=xd) (stop)
> Oct 18 15:52:52 examplehost slapd[24946]: <= acl_mask: [3] mask: auth(=xd)
> Oct 18 15:52:52 examplehost slapd[24946]: => slap_access_allowed: auth
> access granted by auth(=xd)
> Oct 18 15:52:52 examplehost slapd[24946]: => access_allowed: auth
> access granted by auth(=xd)
> Oct 18 15:52:52 examplehost slapd[24946]: conn=10575 op=0 BIND
> dn="cn=proxyuser,ou=system,ou=people,dc=example,dc=de" mech=SIMPLE
> ssf=0
> Oct 18 15:52:52 examplehost slapd[24946]: => bdb_entry_get: found
> entry: "cn=proxyuser,ou=system,ou=people,dc=example,dc=de"
> Oct 18 15:52:52 examplehost slapd[24946]: conn=10575 op=0 RESULT
> tag=97 err=0 text=
> Oct 18 15:52:52 examplehost slapd[24946]: conn=10575 op=1 SEARCH
> RESULT tag=101 err=18 nentries=0 text=serverSort control: No ordering
> rule
> Oct 18 15:52:52 examplehost slapd[24946]: conn=10575 op=1 do_search:
> get_ctrls failed
> Oct 18 15:52:52 examplehost slapd[24946]: conn=10575 op=2 UNBIND
> Oct 18 15:52:52 examplehost slapd[24946]: conn=10575 fd=28 closed
> ...
>
> Is someone able to tell me what specific attributes I have to set for
> simple passwd/group/sudoers listing/sorting?
>
>
> Thank you.
>
> On Mon, Oct 18, 2010 at 09:45, Benjamin Griese <der.darude@gmail.com> wrote:
>> Hi diego,
>>
>> thanks for you advise. I created two new Overlays as you said and
>> tried to set the attribute-set that I googled from some other guys.
>> These are probably wrong. Finally, that solved the messages that
>> appeared in the slapd log, but didn't solve the problem on the solaris
>> hosts.
>> Too bad. :/
>>
>> While reading to the log file once again, I find it quite strange,
>> that the client is asking for specific objectClasses and Attributes
>> that doesn't exist in my DIT.
>> I've imported the solaris.schema while preparing the DIT and setup the
>> "nisDomainObject" in the root Object, because the Client asked for
>> that in the autoconfig-process.
>> But the rest is from duaconfig.schema. By looking through the
>> solaris.schema, the requested obj and attr below are in there. But
>> this is all in all just guess work.
>>
>> for example:
>>
>> Oct 16 19:15:00 examplehost slapd[24946]: conn=1026 op=102 SRCH
>> base="ou=people,dc=example,dc=de" scope=2 deref=3
>> filter="(&(objectClass=NisKeyObject)(uidNumber=3))"
>> Oct 16 19:15:00 examplehost slapd[24946]: conn=1026 op=102 SRCH
>> attr=nisPublickey nisSecretkey
>>
>> Oct 16 19:15:00 examplehost slapd[24946]: conn=1026 op=103 SRCH
>> base="ou=people,dc=example,dc=de" scope=2 deref=3
>> filter="(&(?objectClass=SolarisUserAttr)(uid=sys))"
>> Oct 16 19:15:00 examplehost slapd[24946]: conn=1026 op=103 SRCH
>> attr=uid SolarisUserQualifier SolarisAttrReserved1
>> SolarisAttrReserved2 SolarisAttrKeyValue
>>
>> Oct 16 19:15:00 examplehost slapd[24946]: conn=1026 op=104 SRCH
>> base="ou=projects,dc=example,dc=de" scope=2 deref=3
>> filter="(&(?objectClass=SolarisProject)(?=undefined))"
>> Oct 16 19:15:00 examplehost slapd[24946]: conn=1026 op=104 SRCH
>> attr=SolarisProjectName SolarisProjectID description memberUid
>> memberGid SolarisProjectAttr
>>
>> LDIFs of the overlays:
>>
>> version: 1
>>
>> dn: olcOverlay={4}sssvlv,olcDatabase={1}hdb,cn=config
>> objectClass: olcSssVlvConfig
>> objectClass: olcOverlayConfig
>> objectClass: olcConfig
>> objectClass: top
>> olcOverlay: {4}sssvlv
>>
>> =========================================
>>
>> version: 1
>>
>> dn: olcOverlay={5}valsort,olcDatabase={1}hdb,cn=config
>> objectClass: olcValSortConfig
>> objectClass: olcOverlayConfig
>> objectClass: olcConfig
>> objectClass: top
>> olcOverlay: {5}valsort
>> olcValSortAttr: memberuid ou=groups,dc=example,dc=de alpha-ascend
>> olcValSortAttr: uid ou=people,dc=example,dc=de alpha-ascend
>>
>> Actually these seems to be a question to the Solaris LDAP Mailinglist,
>> am I right?
>> But if you have an further hints, these are much appreciated.
>>
>> Thanks and kind regards, Benjamin.
>>
>>
>> On Fri, Oct 15, 2010 at 18:41, Diego Lima <lists@diegolima.org> wrote:
>>> Hi Benjamin,
>>>
>>> It looks like your LDAP client is asking the server to return ordered
>>> results from looking at this line:
>>>
>>>> tag=101 err=18 nentries=0 text=serverSort control: No ordering rule
>>>
>>> You may want to take a look at the server-side sorting overlay
>>> (slapo-sssvlv) and/or the value sorting overlay (slapo-valsort) and
>>> see if activating them on the server will fix your problems.
>>>
>>>
>>> --
>>> Diego Lima
>>> http://www.diegolima.org
>>>
>>
>>
>>
>> --
>> 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
>>
>
>
>
> --
> 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
>
--
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