directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeffrey Reynolds" <jeffrey.james.reyno...@gmail.com>
Subject Re: ApacheDS and Samba
Date Sun, 17 Apr 2011 03:42:04 GMT
Just a few things.  Wiki page?  Excellent idea.  If I ever get this working 
I'll try to throw it together over a weekend.  There are a few more issues, 
the samba schema is missing a few more attributes, and seems like it needs 
an overhaul anyway.  I'm wondering if its planed to be updated in version 
2.0.  Anyway, those items seem inconsequential enough, just limit a bit of 
functionality.  Anyway, the biggest problem is that this is what my issue 
appears to be.  Once an object is created with a given set of objectClasses, 
it can only be referenced by those object classes.  For example, I created 
an inetOrgPerson, which also includes organizationPerson, person, and top 
objectClasses.  If I run ldapsearch looking for anyone of those 
objectClasses, I can find that entry.  Later I can add another objectClass 
to the entry, say posixAccount, but ldapsearch returns nothing for that 
entry when search for the "objectClass=posixAccount" attribute.  However, if 
I create an object that has all five objectClasses, then searching for any 
of them will return a result.

This is why I wasn't able to log in as any of the accounts I created, or any 
of my original accounts that I modified to have Samba attributes.  Whatever 
mechanism Apach DS uses for it's search mechanism seems to not recognize 
objectClasses added after object creation.  Take this modify ldif file:

dn: uid=user,ou=People,dc=example,dc=com
changetype: modify
add: objectClass
objectClass: sambaSamAccount
objectClass: posixAccount
objectClass: shadowAccount
-
add: gidnumber
gidnumber: 513
-
add: homedirectory
homedirectory: /home/user
-
add: sambaSID
sambaSID: S-1-5-21-LOOOONG-NUUUUUUMBER-61011
-
add: uidnumber
uidnumber: 30010


When adding these attributes to an existing user object:
ldapsearch -h ldapserver -p 389 -b "ou=Peopledc=example,dc=com" 
"objectClass=posixAccount"

Does not return the object.  However, if I create a new object with:

dn: uid=user,ou=People,dc=example,dc=com
changetype: add
objectClass: sambaSamAccount
objectClass: posixAccount
objectClass: shadowAccount
objectClass: top
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
gidnumber: 513
homedirectory: /home/user
sambaSID: S-1-5-21-LOOOONG-NUUUUUUMER-61011
uidnumber: 30010
cn: user
sn: user
uid: user

The freshly created account is returned.  I've tried this with other 
objectClasses and the same seems to hold true, an LDAP searchRequest will 
not retun any objects when the filter specifies an objectClass added to the 
object after creation.  I'm going to open a bug on it, but hope this is an 
isolated incident.  Anyway, I'll post more info on it if I can figure 
anything out on my own.

-Jeff


> <snip/>
>>
>> It wasn't until I fired up Wireshark that I saw my real problem.  By the 
>> way, Wireshark is one of the single best utilities for diagnosing network 
>> communication problems, my hats off to those guys.
> +1 !
>>   Anyway, I was watching the packet flow between Samba and LDAP, and 
>> after a bit of this activity, I saw that Samba was in fact asking for my 
>> uid from the LDAP server.  Samba uses two filters to ask for a user 
>> account, it filters users by "uid=user" and 
>> "objectclass=sambaSamAccount".  Applying those two filters, it did not 
>> find "uid=user".
> (&(uid=xxx)(objectClass=sambaSamAccout)) ?
>
>> So used ldapsearch to do run my own search.  When I search for 
>> "uid=user", it came back without issue,
> Does the entry contains objectClass=sambaSamAccout ?
>
>> but adding the "objectClass=sambaSamAccount" filter it returned nothing. 
>> I double checked directory studio, and sure enough, uid=user has the 
>> "objectClass=sambaSamAccount" attribute.  So I searched for any objects 
>> that had the "objectClass=sambaSamAccount" inside my user group.  I found 
>> that both "uid=root" and "uid=nobody" had this attribute and were 
>> returned by the search.  So I thought, what happens when I try to access 
>> Samba using the root account?  I opened up Explorer, used the root 
>> account and password I set up during smbldap-populate, and BLAM.  Access 
>> to the share.  I checked the Apache DS logs later and found references to 
>> another missing and ignored attribute, "sambaMaxPwdAge", but now I 
>> believe that the missing attributes were simply just red herrings.
> Just one important thing to understand :
> - adding a new attribute to an objectclass will *not* modify the existing 
> entries by adding some values into those entries. You have to update all 
> of them accordingly to the modified schema. That means you have to do a 
> LDAP modify which adds the newly added AT with a value to all the entries.
>
> It's like if you have added a new column in an existing table in a data 
> base, the existing rows will not magically set some value in this column.
>>
>>
>> So I'm left with two questions, why can't Apache DS add the new attribute 
>> but LAM can (both use the same admin dn)?
> I think Stefan replied. Bug in Studio. Refresh the connection works.
>
>> And the big one, the $64,000 question, why does Apache DS return 2 uid's 
>> when search for "objectClass=sambaSamAccount", but doesn't return my user 
>> accounts, when the "objectClass=sambaSamAccount" attribute is present in 
>> all of them?
> One more question : did you restart the server after all those 
> modifications ?
>
> Also what would be cool is to activate the logs on the server and do a 
> session where you try to log with root and your user. We can analyse the 
> log if you send them to us (botch the password before !). You can even 
> send them to me if you don't want any confidential info to be shared on 
> the web.
>
> Be aware that logs can be *very* verbose (debug mode).
>
> At the  end, when it'll work, I think we would have to create some wiki 
> page explaining all this painful process...
>
> -- 
> Regards,
> Cordialement,
> Emmanuel L├ęcharny
> www.iktek.com
>
> 


Mime
View raw message