Hello list,
I'm trying to bind a Solaris 10 Update 6 to a Windows Active Directory.
Users
and Groups are working, but netgroups don't work. What I did is that I
used
snoop to capture the ldap query and the following showed up:
I used the following command line to configure ldapclient:
No. Time Source Destination Protocol
Info
7 0.006628 157.163.247.19 157.163.248.31 LDAP
32919 > ldap [PSH, ACK] Seq=106 Ack=23 Win=49640 [TCP CHECKSUM INCORRECT]
Len=285| searchRequest(2) "OU=Netgroups,OU=ErlF,OU=U
NIX,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net" wholeSubtree
Lightweight-Directory-Access-Protocol
LDAPMessage searchRequest(2)
"OU=Netgroups,OU=ErlF,OU=UNIX,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net"
wholeSubtree
messageID: 2
protocolOp: searchRequest (3)
searchRequest
baseObject:
OU=Netgroups,OU=ErlF,OU=UNIX,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net
scope: wholeSubtree (2)
derefAliases: derefAlways (3)
sizeLimit: 0
timeLimit: 30
typesOnly: False
Filter: (&(objectClass=nisNetGroup)(cn=netgroup))
attributes: 2 items
Item: nisnetgrouptriple
Item: membernisnetgroup
[Response In: 8]
controls: 2 items
Item
controlType: 1.2.840.113556.1.4.473 (sortKeyList)
criticality: True
SortKeyList: 2 items
Item
attributeType: cn
Item
attributeType: uid
Item
controlType: 2.16.840.1.113730.3.4.9
(LDAP_CONTROL_VLVREQUEST VLV)
criticality: True
controlValue: 300F020100020203E7A006020101020100
No. Time Source Destination Protocol
Info
8 0.007149 157.163.248.31 157.163.247.19 LDAP
searchResDone(2) unavailableCriticalExtension (00000057: LdapErr:
DSID-0C09068F, comment: Error processing control, data 0, ve
ce) [0 results]
Lightweight-Directory-Access-Protocol
LDAPMessage searchResDone(2) unavailableCriticalExtension (00000057:
LdapErr: DSID-0C09068F, comment: Error processing control, data 0, vece)
[0 results]
messageID: 2
protocolOp: searchResDone (5)
searchResDone
resultCode: unavailableCriticalExtension (12)
matchedDN:
errorMessage: 00000057: LdapErr: DSID-0C09068F, comment:
Error processing control, data 0, vece
[Response To: 7]
[Time: 0.000521000 seconds]
What I don't get here is what the ,,controls: 2 items'' is about. It seems
to
be an enhanced query that uses some advanved ldap protocol ability that my
server doesn't seem to understand. If I manually do the very same query
and leave the control out in a perl script, I get the result that I
would have assumed:
(ad027088pc) [~/work/ldap] cat demonstrate.pl
#!/usr/bin/perl -w
use strict;
use warnings FATAL => 'all';
use Net::LDAP;
my $ldap = Net::LDAP->new("deerlf0a90.ww004.glanzmann.net", version => 3);
my $mesg = undef;
my $result = undef;
$mesg =
$ldap->bind("CN=ADLDAPF,OU=ErlF,OU=User,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net",
password => 'password here') || die ("Could not authenticate: $!");
$mesg->code && die $mesg->error;
$mesg = $ldap->search(filter=>"(&(objectClass=nisNetGroup)(cn=umc_test))",
attrs => ['nisnetgrouptriple', 'membernisnetgroup'],
base =>
"OU=Netgroups,OU=ErlF,OU=UNIX,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net");
$mesg->code && die $mesg->error;
my @entries = $mesg->entries;
for my $entry (@entries) {
$entry->dump;
}
$ldap->unbind;
(ad027088pc) [~/work/ldap] ./demonstrate.pl
------------------------------------------------------------------------
dn:CN=umc_test,OU=Netgroups,OU=ErlF,OU=UNIX,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net
nisNetgroupTriple: (deerlf0x23.erlf.glanzmann.de,-,)
(deerlf0x23,-,)
(deerlf0v51,-,)
(deerlf0v51.erlf.glanzmann.de,-,)
(erld624x.erlf.glanzmann.de,-,)
(ad027088pc,-,)
(ad027088pc.erlf.glanzmann.de,-,)
This is how I configured the ldapclient:
ldapclient -v manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a
proxyDN=CN=ADLDAPF,OU=ErlF,OU=User,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net
\
-a proxyPassword=z61pAEQMsz61pAEQMs \
-a
defaultSearchBase=OU=ErlF,OU=User,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net
\
-a domainName=erlf.glanzmann.de \
-a defaultServerList=157.163.248.31 \
-a attributeMap=group:userpassword=userPassword \
-a attributeMap=group:memberuid=memberUid \
-a attributeMap=group:gidnumber=gidNumber \
-a attributeMap=passwd:gecos=cn \
-a attributeMap=passwd:gidnumber=gidNumber \
-a attributeMap=passwd:uidnumber=uidNumber \
-a attributeMap=passwd:homedirectory=unixHomeDirectory \
-a attributeMap=passwd:loginshell=loginShell \
-a attributeMap=shadow:shadowflag=shadowFlag \
-a attributeMap=shadow:userpassword=userPassword \
-a objectClassMap=group:posixGroup=group \
-a objectClassMap=passwd:posixAccount=user \
-a objectClassMap=shadow:shadowAccount=user \
-a
serviceSearchDescriptor=passwd:OU=ErlF,OU=User,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net?sub
\
-a
serviceSearchDescriptor=group:OU=ErlF,OU=User,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net?sub
\
-a
serviceSearchDescriptor=netgroup:OU=Netgroups,OU=ErlF,OU=UNIX,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net?sub
And now my questions:
- Can I tell Sun's native client to don't use the ,,control''
statements? For users and groups it doesn't use a control
statement
in the query.
- Or is the problem caused by a misconfiguration and/or missing
objects in my Active Directory (nss-ldap works with that out
of the box)?
