# samba with ldap, some users can't login; solved

## hika

I have already some time a weird problem with samba. Everything was working good and in december I decided to implement ldap. Everything works including tls.

But two users that could before login can't now. My own account has no problems

All three account have full rights both in samba and in ldap and experience no problems loging in to Linux or ldap both on the server and on other machines on the network. One of them is the root account.

If I call net rpc ... I get:

```
Could not connect to server 127.0.0.1

Connection failed: NT_STATUS_UNSUCCESFUL
```

If I mistype the password I get an added 

```
The username or password was not correct
```

So authentication to LDAP works

If I call net -U hika  rpc it works fine.

If I try to login to one WinXP machine running in vmware I get the massage (translated from dutch)

```
The system cannot log you in because of the following error

Some equipment that is connected to the system isn't working 
```

On an other machine I get an undefined error

I cannot find any deferences between the accounts

And I am out of trying and scanning the log. Disabling tls doesn't have any effect.

Please any suggestions are welcome!

HikaLast edited by hika on Mon Feb 08, 2010 3:00 pm; edited 2 times in total

----------

## hika

I now found the following error from samba in responce to the failed net rpc call

```
auth/auth_sam.c:check_sam_security(353)

check_sam_security: make_server_info_sam() failed with 'NT_STATUS_UNSUCCESFULL'
```

Looking for this error I found some remark on ldapsam:trusted in smb.conf. 

I had it on yes because as I thought and think I put everything in ldap. But turning it off solves the problems. 

Now I have to find what is missing in ldap. It can't be that their main groups in ldap are different from on the server, because that goes for my account to???

Any ideas?

Hika

----------

## Rexilion

 *hika wrote:*   

> I now found the following error from samba in responce to the failed net rpc call
> 
> ```
> auth/auth_sam.c:check_sam_security(353)
> 
> ...

 

I have 0 knowledge on LDAP, but this might help:

http://lists.samba.org/archive/samba/2005-November/114386.html

----------

## hika

Thanks,

That's precisely where I got the hint about ldapsam:trusted but my problem is not intermittent, but 100% reproducible. 

The weirdest is that it is user specific, but the accounts in ldap are identical. I found out that I hadn't put the machine possix accounts in ldap, but than why does it work with one user and not with the others.

The non working users are:

root exists both in ldap and local but with a different preferred possix/linux group (wheel,10 in ldap)

admin exists only in ldap, I just removed it on the server, but never existed on any workstation and has main group smbusers

the working user is my own hika it exists everywhere with the same uidnumber 1000 but in ldap has main group smbusers

I removed all the specific samba groups from the server to prevent conflict, although the uidnumbers where the same.

In pam.d/system-auth I have ldap auth first as sufficient with unix second as required. This way it only uses ldap if available, but falls back to unix if not or if the user doesn't exist in ldap.

in pam/samba I have ldap as sufficient after smbpass. Maybe I should switch those?

But still everything I find should affect all users or none??

Hika

----------

## hika

I am suddenly thinking. When I moved from the tdb backend to ldap I didn't wipe the tdb database. Is it possible there is some conflict between those two. And if so how do I wipe the old tdb database without losing things I need?

Hika

----------

## hika

Now I'm coming somewhere. It's getting more logical. I followed my inspiration and wiped the tdbsam database (after backing up and killing samba) and restarted samba

inserted the ldappassword into samba again and started some testing.

The errors with net rpc didn't change but ...

root suddenly could login again to samba , admin not and hika could, but can access only shares it gets rights to through a group.

Conclusion rights granted through a user go wrong. (hika has a local profile on the the windows machine, but admin not)

I guess when loging in it tries to get access to the profiles directory. Root gets access any way, hika falls back to local and admin fails.

Because the old tdbsam was still there hika could fall back to old information.

hika

----------

## hika

I now have most things working. It looks like all had to do with conflicts.

I re-added the admin account manually renaming it to smbadmin and now it can do everything. With one exception. One of the shares gets its rights through a group that exists both in ldap and on the server. Although smbadmin is a member in ldap it doesn't get rights. probably it would if I deleted the group on the server, but I need the group even if ldap is down.

Root can login to windows but afterwards cannot access the server. And Root also still gets an error on net rpc ... but smbadmin not.

It looks like it cannot decide between ldap and local passwrd/group information.

Hika

----------

