Bug 7966 - Group name membership resolution with winbind get error
Group name membership resolution with winbind get error
Status: RESOLVED WORKSFORME
Product: Samba 3.2
Classification: Unclassified
Component: Client tools
3.2.15
x86 Linux
: P3 critical
: ---
Assigned To: Volker Lendecke
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-21 01:48 UTC by Pavel V Samsonov
Modified: 2011-02-23 03:02 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel V Samsonov 2011-02-21 01:48:59 UTC
Good day. I have samba as windows domain member.

# cat /etc/nsswitch.conf | grep winbind
passwd: 	files winbind
shadow: 	files winbind
group:  	files winbind

/etc/samba/smb.conf:
.......
        idmap backend = tdb
        idmap alloc backend = tdb
        idmap uid = 10000 - 14000
        idmap gid = 10000 - 14000
        winbind enum users = Yes
        winbind enum groups = Yes
.......

# getent group test
test:x:10334:user

# groups user | grep test
# echo $?
1
#

I see that samsonov is member of group test, but this group not in list of groups of user samsonov.

I don't sure, that it is problem of samba code (winbind module), but help me please.
Comment 1 Volker Lendecke 2011-02-21 13:23:19 UTC
Does that also happen if you log in using pam or wbinfo -a first?

Volker
Comment 2 Pavel V Samsonov 2011-02-22 01:31:46 UTC
My production example:
For my known user:

root@mailsrv:/etc# wbinfo -a samsonov%<My passwd>
plaintext password authentication succeeded
challenge/response password authentication succeeded
root@mailsrv:/etc# wbinfo -t
checking the trust secret via RPC calls succeeded
root@mailsrv:/etc# wbinfo -i dolgushev
dolgushev:*:10257:10004::/home/dolgushev:/bin/bash


For problem group:

root@mailsrv:/etc# getent group gzsupport-write
gzsupport-write:x:10332:buzurtanov,dcvetkov,dolgushev,ismirnov,kalistratova,lmakarova,pervuhina,shishanova,skvorcova,smirnovanv,vershinin,yaroslav
root@mailsrv:/etc# id buzurtanov | grep gzsupport-write
root@mailsrv:/etc# id dcvetkov | grep gzsupport-write
uid=10669(dcvetkov) gid=10004(domain users) группы=10004(domain users),10005(fmregions-read),10332(gzsupport-write),10006(curator-read),10007(budgetmethod-read),10169(gz-write),10097(budgetx-write),10008(budgetdev-read),10170(gzsupport),10009(fmlibrary-read),10101(budgetx-read),10010(budgetversion-read),10011(urm-read),10012(fmregionsdata-read),10013(fm-read),10031(gzsource-write),10319(agrtender-read),10014(fmversions-read),10208(ftp-frgk)
root@mailsrv:/etc# id dolgushev | grep gzsupport-write
root@mailsrv:/etc# id ismirnov | grep gzsupport-write
root@mailsrv:/etc# id kalistratova | grep gzsupport-write
root@mailsrv:/etc# id yaroslav | grep gzsupport-write

If I use this hack:
root@mailsrv:/etc# getent group gzsupport-write >> /etc/group

root@mailsrv:/etc# id dolgushev | grep gzsupport-write
uid=10257(dolgushev) gid=10004(domain users) группы=10004(domain users),10332(gzsupport-write),10005(fmregions-read),10006(curator-read),10007(budgetmethod-read),10169(gz-write),10097(budgetx-write),10008(budgetdev-read),10170(gzsupport),10009(fmlibrary-read),10101(budgetx-read),10010(budgetversion-read),10011(urm-read),10012(fmregionsdata-read),10013(fm-read),10031(gzsource-write),10319(agrtender-read),10014(fmversions-read),10208(ftp-frgk),10131(tender)
root@mailsrv:/etc# id ismirnov | grep gzsupport-write
uid=10766(ismirnov) gid=10004(domain users) группы=10004(domain users),10332(gzsupport-write),10005(fmregions-read),10006(curator-read),10007(budgetmethod-read),10169(gz-write),10097(budgetx-write),10008(budgetdev-read),10170(gzsupport),10009(fmlibrary-read),10101(budgetx-read),10010(budgetversion-read),10011(urm-read),10012(fmregionsdata-read),10013(fm-read),10031(gzsource-write),10319(agrtender-read),10243(delo-read),10014(fmversions-read),10208(ftp-frgk)

After some pice of time (12-24 hours) name resolving may be OK, but I don't undestand - why when getent group is right, id <user> and groups <user> display wrong information and users havn't his file permissions.

Thanks! I houpe You help me :)!
Comment 3 Volker Lendecke 2011-02-23 01:18:01 UTC
Ok, thanks. I meant does this happen also for the users you did log in via PAM, CIFS or wbinfo -a? You logged in as user samsonov, but you tried the id command for users different from samsonov. I would like to know if this problem also happens for the users you did log in as via winbind (i.e. the methods I mentioned above).

With best regards,

Volker Lendecke
Comment 4 Pavel V Samsonov 2011-02-23 02:30:28 UTC
Ok! I don't know other users passwords. I add in domain samsonov to gzsupport-write 10 minutes ago.

root@mailsrv:/etc# getent group gzsupport-write
gzsupport-write:x:10332:buzurtanov,dcvetkov,dolgushev,ismirnov,kalistratova,lmakarova,pervuhina,samsonov,shishanova,skvorcova,smirnovanv,vershinin,yaroslav
root@mailsrv:/etc# getent group gzsupport-write | grep samsonov
gzsupport-write:x:10332:buzurtanov,dcvetkov,dolgushev,ismirnov,kalistratova,lmakarova,pervuhina,samsonov,shishanova,skvorcova,smirnovanv,vershinin,yaroslav

root@mailsrv:/etc# id samsonov | grep gzsupport-write

(not work)

After authentication:
root@mailsrv:/etc# wbinfo -a samsonov%<passwd>
plaintext password authentication succeeded
challenge/response password authentication succeeded

root@mailsrv:/etc# id samsonov | grep gzsupport-write
uid=10006(samsonov) gid=10004(domain users) группы=10004(domain users),10005(fmregions-read),10332(gzsupport-write),10006(curator-read),10007(budgetmethod-read),10097(budgetx-write),10008(budgetdev-read),10009(fmlibrary-read),10101(budgetx-read),10334(test),10010(budgetversion-read),10011(urm-read),10012(fmregionsdata-read),10013(fm-read),10319(agrtender-read),10014(fmversions-read)


Sorry! May be this OK.

Comment 5 Volker Lendecke 2011-02-23 03:02:22 UTC
Finding group memberships of users without knowing their passwords is very difficult for a Active Directory domain member. There is the S4U2Self feature of Kerberos, but that is not implemented in Samba yet. So we have to do the same operations against AD that the DC itself does upon authentication. In many scenarios, AD ACLs prevent this. So in the past we did not put much focus on this. If however it does not work when the user has recently authenticated, we have a high-priority bug that we will work on.

I'm closing this bug as "worksforme". Please re-open it if you have a case where it does not work after authenticating.

Thanks,

Volker