Re [Samba] LDAP adding workstation accounts fails (but
not really???)
Adam Williams
awilliam at mdah.state.ms.us
Thu Feb 28 18:55:56 GMT 2008
well su -l testing\$ fails because nss_ldap can't find testing$ in your
ldap tree. does testing$ exist in your ldap tree? if so, what is the
full dn of it? run something like:
ldapsearch -D "cn=Manager,dc=iwu,dc=edu" -b
"uid=testing$,ou=People,dc=iwu,dc=edu" -w xxxxxxx -x
and
ldapsearch -D "cn=Manager,dc=iwu,dc=edu" -b
"uid=testign$,ou=Computers,dc=iwu,dc=edu" -w xxxxxxx -x
does either one return testing$ in your tree? see, you can't add a
machine account if nss_ldap can't resolve the user named testing$, so
you need to figure out why its not seeing the user testing$
Pat Riehecky wrote:
> Again, thanks ever so much for the assistance on this, but it seems I am
> without luck....
>
> my /etc/ldap.conf now reads
> # cat /etc/ldap.conf
> URI ldap://127.0.0.1
> BASE dc=iwu,dc=edu
> pam_filter objectclass=posixAccount
> pam_login_attribute uid
> pam_crypt local
> nss_base_passwd dc=iwu,dc=edu?sub
> nss_base_passwd ou=People,dc=iwu,dc=edu?one
> nss_base_passwd ou=Computers,dc=iwu,dc=edu?one
>
> the half entry was still present in ldap, so I removed it and attempted
> a re-join. No dice, still identical behavior. I also tried the su you
> suggested, it too failed.
>
> # su -l testing\$
> Unknown id: testing$
>
> This is strange, because I can su to other users in the ou=People tree,
>
> # su - prieheck
> prieheck at debian:~$ exit
>
> Continuing to be puzzled,
> Pat
>
> On Thu, 2008-02-28 at 09:01 -0600, Adam Williams wrote:
>
>> you need in ldap.conf:
>>
>> nss_base_passwd ou=People,dc=iwu,dc=edu?one
>> nss_base_passwd ou=Computers,dc=iwu,dc=edu?one
>>
>> and then see if you can su -l testing\$
>>
>> (it should complain about no home directory but let you su to the
>> user)
>>
>>
>> Pat Riehecky wrote:
>>
>>> Hello,
>>>
>>> Still hitting the same wall, (Oh yeah, uhh... Debian linux samba
>>> packages from SID)
>>>
>>> # net rpc join -S TESTING -U root%password
>>> Creation of workstation account failed
>>> Unable to join domain TESTING
>>>
>>> dn: uid=testing$,ou=Computers,dc=iwu,dc=edu
>>> objectClass: top
>>> objectClass: account
>>> objectClass: posixAccount
>>> cn: testing$
>>> uid: testing$
>>> uidNumber: 1001
>>> gidNumber: 515
>>> homeDirectory: /dev/null
>>> loginShell: /bin/false
>>> description: Computer
>>> gecos: Computer
>>>
>>> my /etc/ldap/ldap.conf reads (it has been hard linked to /etc/ldap.conf)
>>>
>>> # cat ldap.conf
>>> URI ldap://127.0.0.1
>>> BASE dc=iwu,dc=edu
>>> pam_filter objectclass=posixAccount
>>> pam_login_attribute uid
>>> pam_crypt local
>>> nss_base_passwd dc=iwu,dc=edu?sub
>>>
>>> Here are the ldap lines from my smb.conf
>>> passdb backend = ldapsam:ldap://localhost
>>> ldap group suffix = ou=Group
>>> ldap idmap suffix = ou=Idmap
>>> ldap machine suffix = ou=Computers
>>> ldap passwd sync = Yes
>>> ldap suffix = dc=iwu,dc=edu
>>> ldap ssl = no
>>> ldap user suffix = ou=People
>>>
>>> Seems like I have missed something.... Just not sure what
>>> Pat
>>>
>>> On Tue, 2008-02-26 at 13:30 -0800, Dirk Kleinhesselink wrote:
>>>
>>>
>>>> On Tue, 26 Feb 2008, Pat Riehecky wrote:
>>>>
>>>> Assuming you're running linux or a similar sytem (nsswitch) - I think
>>>> you need to set the search scope for your LDAP lookups. In my
>>>> /etc/ldap.conf (the nsswitch ldap search configuration) I have:
>>>>
>>>> nss_base_passwd set to my base DN with scope sub:
>>>>
>>>> nss_base_passwd dc={},dc={}?sub
>>>>
>>>> The default is to do something like:
>>>>
>>>> nss_base_passwd ou=People,dc={}.dc={}?one
>>>>
>>>> In my case People and Computers are underneath the base and so the passwd
>>>> search starts at the base and seeks down.
>>>>
>>>> Then in my smb.conf I have the ldap suffix set to my LDAP base
>>>> and the ldap user suffix is set to: ou=People and
>>>> ldap machine suffix to: ou=Computers
>>>>
>>>> Dirk
>>>>
>>>>
>>>>
>>>>> I very much appreciate the help thus far, but I think it has strayed a
>>>>> bit from the actual problem.
>>>>>
>>>>> The problem is that when I join a system to the samba domain it
>>>>> creates /some/ but not all of the required attributes for the computer
>>>>> account. The process then fails as samba looks in the wrong part of my
>>>>> directory server. I would strongly prefer to put the workstation
>>>>> accounts in their own tree (ou=Computers). I added the relevant bits to
>>>>> the smb.conf for this to happen (ldap machine suffix = ou=Computers) and
>>>>> restarted samba. Yet the debug logs show me that, while it executes the
>>>>> machine add script just fine, it is still looking in ou=People. As a
>>>>> leap into absurdity I even rebooted the whole box (in case a shared
>>>>> memory segment was somehow hanging about), still the samba binary is
>>>>> convinced my computer accounts live in ou=People. The process becomes
>>>>> more odd when I can see in the debug log that the samba binary has
>>>>> successfully read in my machine suffix.
>>>>>
>>>>> I find this a bit unusual.
>>>>> Pat
>>>>>
>>>>> On Tue, 2008-02-26 at 09:03 -0800, Chuck Kollars wrote:
>>>>>
>>>>>
>>>>>>> ...Yet, if I search LDAP after the join attempt I
>>>>>>> find: dn: uid=testing$,ou=Computers,dc=iwu,dc=edu
>>>>>>>
>>>>>>>
>>>>>> This convention of a "workstation" account being the
>>>>>> same as a "people" account except with a dollar sign
>>>>>> appended to the name is the way Windows works.
>>>>>> Weird?Yes. Looks wrong?Yes. Needs "fixing"?Maybe Not.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> ...My LDAP logs show it is searching ou=People
>>>>>>> rather than ou=Computers to see if it was added
>>>>>>> successfully. What must I do to make it search
>>>>>>> ou=Computers? ...
>>>>>>>
>>>>>>>
>>>>>> Unfortunately it's pretty easy and pretty common to
>>>>>> use LDAP in a way that doesn't match the "usual" human
>>>>>> definitions of some words. This isn't necessarily
>>>>>> wrong though. If an operation doesn't work, definitely
>>>>>> dig in. But if an operation "works" but appears to use
>>>>>> words differently than your definitions, it may not be
>>>>>> a problem.
>>>>>>
>>>>>> Every LDAP tool has its own settings. Change it for
>>>>>> one tool, and it will still behave the old way for
>>>>>> other tools.
>>>>>>
>>>>>> For `ldapsearch`, there are several settings, the
>>>>>> later of which override the earlier. One is "base" in
>>>>>> a file named something like /etc/openldap/ldap.conf.
>>>>>> This may be overridden by a command line parameter to
>>>>>> `ldapsearch`.
>>>>>>
>>>>>> For LDAP name service lookups (if enabled in
>>>>>> /etc/nsswitch.conf), again there's "base" but this
>>>>>> time in /etc/ldap.conf (a separate file but with a
>>>>>> name very similar to the first one). Sometimes you'll
>>>>>> also find "nss_base_hosts", which takes precedence if
>>>>>> it exists. There may also be a setting on pam_ldap.so.
>>>>>>
>>>>>>
>>>>>> etc.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Now the other half of the question, the part you
>>>>>>> didn't ask, which is not where to "search" but
>>>>>>> where to "store". (Obviously storing in one place
>>>>>>> but searching in the other won't work at all.
>>>>>>> Both storing and searching in the "wrong" place
>>>>>>> may work perfectly well for Samba, yet might be
>>>>>>> inconsistent with some of your other tools and
>>>>>>> procedures.)
>>>>>>>
>>>>>>>
>>>>>> Unfortunately there are a gazillion different ways to
>>>>>> update an LDAP database and they all work differently
>>>>>> and are all configured differently. Are you using some
>>>>>> scripts, or a web application like 'phpldapadmin', or
>>>>>> the `ldapadd` command, or ...; and are you calling it
>>>>>> explicitly or letting it be called from within Samba
>>>>>> via the 'add machine' parameter?
>>>>>>
>>>>>> good luck!
>>>>>>
>>>>>>
>>>>>> -Chuck Kollars
>>>>>>
>>>>>>
>>>>>> ____________________________________________________________________________________
>>>>>> Looking for last minute shopping deals?
>>>>>> Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
More information about the samba
mailing list