On 02/04/13 22:39, Jakub Hrozek wrote:
On Tue, Apr 02, 2013 at 01:42:46PM +0100, Rowland Penny wrote:
With the AD provider you shouldn't be needing any of the options
below.
The AD provider should just default to them.
Is there a reason you are using password binds and not GSSAPI?
OK, I have removed all the lines you suggested and getent stopped
working, examining /var/log/sssd/sssd_DOMAIN.log gives the
reason:
(Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]] [resolve_srv_send]
(0x0400): SRV resolution of service 'AD'. Will use DNS discovery
domain 'DOMAIN'
(Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]] [resolve_srv_cont]
(0x0100): Searching for servers via SRV query '_ldap._tcp.DOMAIN'
(Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]]
[resolv_getsrv_send]
(0x0100): Trying to resolve SRV record of '_ldap._tcp.DOMAIN'
(Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]]
[request_watch_destructor] (0x0400): Deleting request watch
(Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]] [resolve_srv_done]
(0x0020): SRV query failed: [Domain name not found]
(Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]]
[fo_set_port_status]
(0x0100): Marking port 0 of server '(no name)' as 'not working'
(Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]]
[set_srv_data_status]
(0x0100): Marking SRV lookup of service 'AD' as 'not resolved'
It is trying to look up the samba domain name instead of the
the DNS
domain.name, re-adding the following line cures this:
dns_discovery_domain = domain.lan
I see, this is interesting. Does the value of dns_discovery_domain
differ from the value of ad_domain? If not, then I would
consider it a
bug.
I must have misunderstood you, because I turned off 'ad_domain =
domain.lan'. I have now turned it back on again and turned off the
dns_discovery_domain line and it still works.
Rowland
I think there are two options:
1) keep using the ID mapping and tailor the configuration of
the ID
mapper in the SSSD so that it generates the same output as
the winbind
mapper. We've done this before, it's not the nicest looking
configuration, but it works.
What sssd ID mapping seems to do is, get the last part of the SID
and add a number to the front of it, is this correct? and if so
where does the number come from? and is this the way Windows does
it?
Correct, The first number is a hashed value of the domain part
of the
SID
and the "last part of the SID" is usually called the RID.
Can you check if setting ldap_idmap_autorid_compat to True
would yield
the same IDs as winbind does? (Sorry I don't have a box with
winbind
handy and I always forget the details).
I have tried it and no it wouldn't, with S3 winbind I got:
uid=21105(user) gid=20513(domain_users) groups=20513(domain_users)
With the line added into sssd.conf and winbind turned off, I now
get:
uid=201105(user) gid=200513(domain_users)
groups=200513(domain_users)
When you say 'the same output as the winbind mapper', which
winbind
are you refering to, the winbind on the Samba 4 server or the
winbind on the Samba 3 client?
Both actually. You really want to have the IDs consistent
everywhere.
That is the problem, the built into samba4 winbind returns
different
results:
uid=3000016(DOMAIN\user) gid=100(users) groups=100(users)
2) Switch to using POSIX IDs instead of mapping them from
SIDs with
both
winbind and SSSD. All that should be needed on the SSSD side
is set:
ldap_id_mapping = False
to sssd.conf and restart the SSSD (you might need to rm the
cache as
SSSD doesn't really handle UID/GID changes very well yet).
On the winbind side, I'm a little fuzzy on the details, but I
believe
this could be done with "winbind nss info" configuration option.
The problem here is the use of winbind, I cannot get the idmap_ad
backend to work at all, and idmap_rid gives a different uid
>from the
Samba 4 server
So which mapper does the S4 server use?
I do not know, I only know it is different from the S3 winbind.
From where I am 1) sounds like easier to implement since
all you'd be
changing is sssd.conf
I am being to think that the way forward is to stop winbind on
the
Samba 4 server and use sssd instead.
That is a noble goal and one which we wanted to accomplish in the
upcoming 1.10 release, but it was postponed to the next one:
https://fedorahosted.org/sssd/ticket/1534
The Samba server seems to be leveraging an interface only
winbind is
able to serve at the moment to convert SIDs to GIDs on the
server side.
I don't know all the details, sorry, maybe on of the Samba
developers
lurking on this list would chime in.
I don't understand this, by removing the S4 winbind links on the
server and installing sssd 1.9.4, I appear to have got it to work,
I now have consistent uid's & gid's without any real effort.
