[Samba] samba4 DC, internal winbind_server: external idmap problem

[Andy Igoshin]

On Sat, 07 Dec 2013 19:05:51 +0100
steve <steve at steve-ss.com> wrote:
> On Sat, 2013-12-07 at 17:57 +0400, Andy Igoshin wrote:  
> > 
> > i run samba 4.1.2 in DC mode. win7 client joined to this domain
> > successfully.
> > 
> > now i try to configure external idmap.
> > i would like it to use our existing ldap server:
> > 
> > idmap config DOM : backend = rfc2307
> > idmap config DOM : range = 1110000-1119999
> > idmap config DOM : ldap_server = stand-alone
> > idmap config DOM : ldap_url = ldap://ldap.domain.ru
> > idmap config DOM : ldap_user_dn = uid=ldapmaster,cn=ldap.domain.ru
> > idmap config DOM : bind_path_user = cn=dom.domain.ru
> > idmap config DOM : bind_path_group = cn=dom.domain.ru
> > idmap config DOM : cache time = 1800
> > winbind nss info = rfc2307
>
> Phew. I don't think that's gonna go. I'm assuming from this
> configuration, you already have (perhaps a NT) domain but none of
> the information in the same exists in your new AD provision. Did you
> provision the domain from scratch? If not. . .  

i have a new fresh installation of samba4 DC. there are no old NT
domains.


> Maybe the best way to proceed is to to use
>  samba-tool domain classicupgrade
>  on your existing ldap database. There's a howto here:
> http://wiki.samba.org/index.php/Samba4/samba-tool/domain/classicupgrade/HOWTO
> 
> We see many here run into trouble trying to maintain an external
> second idmap database in addition to AD. I strongly recommend
> storing your existing rfc2307 attributes in the same database i.e.
> in AD, along with all the other pertinent machine and user
> information. The classicupgrade will get these across for you.   

we already have ldap-based user management system which contains all
required attributes.

in other words samba-centric infrastructure is not what we want.


> > i created a user 'test2' in samba DC.
> > in ldap.domain.ru there is the user uid=test2,cn=dom.domain.ru
> > with such attributes: 
> > uidNumber = 1113535
> > gidNumber = 1113535
> > objectSid = S-1-5-21-1982177496-2241683161-2840224108-1106 (i got
> > it from samba DC)
> > 
> > when i run wbinfo to get user's info i expect it to go to
> > ldap.domain.ru. but it does not happen. it looks like wbinfo
> > returns values from internal automatic idmap.
> > 
> > # wbinfo -S S-1-5-21-1982177496-2241683161-2840224108-1106
> > 3000019
> > # wbinfo -U 1113535
> > S-1-22-1-1113535
> > 
> > do i misunderstand something?
> > is it possible to use idmap in such mode?
> 
> OK, but remember that wbinfo isn't going to give a realistic view of
> what the file system expects. E.g. does
>  getent passwd test2
> return anything realistic? What do you have for the passwd stanza
> in /etc/nsswich.conf?  

passwd: compat sss


some explanations:

we use sssd which takes data from our ldap-based system.

# getent passwd test2 at dom.domain.ru
test2 at dom.domain.ru:*:1113535:1113535:test2:/home/dom.domain.ru/test2:/bin/bash

[yes, it is multidomain [linux] infrastructure. yes, specifying of domain
name is required. yes, we would like to add samba services into this
infrastructure. as far as i see now it would be enough if just external
idmap works correctly]

[sssd 1.11.2 takes objectSid from ldap-directory. but it can't take domain sid
from ldap and is not able to specify domain sid in sssd.conf.
sssd gets confused while defining domain by objectSid. as result it does
not work. bug in sssd is opened. so now objectSid is not used in sssd,
i try to make idmap using only samba functions]

if wbinfo is not suitable - how may i test working of sid<->uid and
other mappings on samba's side?  


> We can get you there, but we don't have enough information on what
> you have at the moment, especially where and what is stored in your
> ldap currently.  

hope our infrestructure is more clear now. i could add more details
in case of need.


> Cheers,
> Steve  


-- 
Andy Igoshin <ai at vsu.ru>                 Voronezh State University
sip:          ai at vsu.ru                  Network Operation Center
phone: +7 473 2281160, ext. 2020         Voronezh, Russia