On 11/04/13 21:01, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/11/2013 03:33 PM, Rowland Penny wrote:
On 11/04/13 19:50, Dmitri Pal wrote:
On 04/11/2013 02:30 PM, Rowland Penny wrote:
On 11/04/13 18:49, Dmitri Pal wrote:
On 04/11/2013 10:00 AM, Rowland Penny wrote:
On 08/04/13 11:39, Jakub Hrozek wrote:
On Fri, Apr 05, 2013 at 08:15:14PM +0100, Rowland Penny
wrote:
On 05/04/13 19:46, Dmitri Pal wrote:
On 04/05/2013 02:40 PM, Rowland Penny wrote:
On 05/04/13 19:00, Jakub Hrozek wrote:
On Fri, Apr 05, 2013 at 05:36:32PM +0100, Rowland
Penny wrote:
On 05/04/13 17:05, Andreas Schneider wrote:
On Friday 05 April 2013 15:54:41 Rowland
Penny wrote:
On 05/04/13 15:35, Jakub Hrozek wrote:
On Wed, Apr 03, 2013 at 11:20:44AM +0100,
Rowland Penny wrote:
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.
I had a short chat with the Samba Red Hat
maintainer Andreas Schneider (CC-ed) and
he advised against removing winbind from
the server, too.
I'm sure he'll provide a more qualified
answer than I can :-)
Hi, on Samba 4 you get 2 winbind's, one is
based on the S3 code base and I think that
I am right in saying that it will not start
if the samba (AD) daemon is run.
That's correct and the DC needs the 'builtin'
winbind daemon for the DC to function. It
will not work with the s3fs winbind.
The other is built into the samba daemon
and requires the creation of a couple of
symlinks to use winbind in /etc/nsswitch.
What do you mean here?
If, as I do, you compile Samba 4, you have to
create a couple of symlinks:
ln -s /usr/local/samba/lib/libnss_winbind.so.2
/lib/libnss_winbind.so ln -s
/lib/libnss_winbind.so
/lib/libnss_winbind.so.2
Without these, you do not get any domain users
etc from getent.
Truth be told, I've never compiled Samba from
scratch myself, but the nssswitch libraries must
be installed to /lib{,64}, are you sure there
isn't just a configure time switch for that?
If you are talking about libnss_winbind.so, then as
far as I know, no there isn't, you just have to
create the two symlinks and add 'winbind' to the
passwd & group lines in /etc/nsswitch.conf and it
works. If you do add the links etc then sssd does
not work on the S4 server. As sssd seems to work
better than winbind then I shall continue to use
it, but what I cannot understand is why do I seem
to get the feeling that you are trying to talk me
out of using sssd.
Rowland
On the samba file server or DC there other things
that file server gets directly from winbind that sssd
does not have yet. We are concerned that this would
cause issues for you that you yet have not seen. That
would be the reason. If you are willing to continue
trying and are prepared to encounter issues and
report back then we are OK.
Could you give me some idea what sssd doesn't do that
winbind does?
As far as I can see, I get (via getent): uidNumber
gidNumber unixhomedirectory loginShell
There is an interface for SID to name conversion in Samba
and currently only winbind implements the interface. We
wanted to have a compatible implementation done for 1.10
but we're probably not going to make it.
I don't know exactly from the top of my head what
functionality the samba server uses this interface for.
Maybe Andreas or Sumit know?
which as far as I can see is what winbind would give
me.
I can create directories & files and change ownership
to a domain user &/or domain group, or in other words,
I cannot tell the difference between using winbind or
sssd except for the constant uidnumbers & gidnumbers.
_______________________________________________
sssd-users mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
OK, I admit it, I was wrong, you cannot use sssd ad mode on a Samba 4
server instead of winbind.
Everything seemed to work ok until I tried to use cifs to
mount the users homedirectory from the S4 server. It
mounted ok and if you checked the user permissions on the
the server & client they matched, both names & uid's.
Getfacl showed that the user should be able to write to the
share, only the user couldn't, the user had no rights to
their own directory. I can only assume that cifs somehow
uses winbind on the server and gets the uidnumbers that S4
winbind gives, these are different to what sssd comes up
with.
What (so far) seems to work is: use winbind on the S4
server, set the uidNumber & gidNumber etc in the S4 LDAP
for the users, no need for posix objectclasses. Then set up
sssd on the linux clients to pull from ldap using
kerberos.
Rowland
Yes that would work however another scenario that we expect
to more or less work is: S4 DS + winbind on the server side
using rid ID mapping algorythm, no UID/GID in LDAP, client is
SSSD 1.9 with AD back end and id mapping used.
You have lost me there, are you referring to the S4 winbind
built into the S4 samba daemon?
Sorry for typo, if confused the whole thing. I meant "Samba FS +
winbind"
if so, there does not seem to be any documentation anywhere
that I can find. As I said, I tried to get winbind on the
clients working with both id_map rid & ad backends and could
not get either to work. Whatever I use, has to come up with the
same UID/GID that the S4 winbind does, because that is what the
unix server seems to require. In fact I will state it plainly,
whatever is used must produce exactly the same Unix information
as the S4 winbind.
Correct and I am curious why it did not work because we used the
same algorithm in SSSD id map translation as winbind rid uses
with only one difference - SSSD can have additional ranges to
support multiple domains. If it is a bug in SSSD it is a major
one that we need to fix ASAP. If it is a bad configuration I want
to get to the core of the problem and have a clear set of
instructions how to set things up because we need it for the next
round of work we will start later this spring-summer.
Rowland
That should work. What would fail are some client side
utilities that grew some interfaces to the winbind. But we
plan to address them down the road.
Thanks for investigation! It is a valuable information for
us.
You have probably based your work on the S3 winbind, this is a
separate daemon. If you run S4 as an AD DC you do not get a
separate winbind daemon, it is now built into the samba daemon, the
S3 samba daemon is not to be confused with the S3 smbd daemon which
the samba daemon runs to get the s3fs fileserver backend. The S4
winbind seems to operate differently from S3 winbind and has, I
understand, a different code base.
On the samba 4 server setup as per the samba4 howto, running as an
AD DC, getent passwd username gives:
DOMAIN\username:*:3000017:100::/home/DOMAIN/username:/bin/bash
There does not seem to be a way to change the base for the UID
(3000017) and the GID(100) comes from the RID 513, so to use sssd
with the ad backend, the users uid produced by sssd (based on the
line above) would have to be 3000017, not what it is coming up with
at the moment.
What I am doing at the moment is setting the users uidNumber etc on
the S4 server and using sssd ldap to pull the info and it does seem
to work
This thread is too long for me to scan through and check, but are you
using:
ldap_idmap_autorid_compat = True
No, but to be honest, after trying to get winbind to work similar to
what you are suggesting, I am off any form of idmapping, this is not how
windows works and I think that idea should be layed to rest.
in your sssd.conf? If not, that's why you're getting different IDs. By
default, we use a deterministic algorithm to create the IDs, but
winbind's autorid algorithm requires that they all start at the first
slot and go upwards from there.
All S4 winbind uid's seem to start at 3000000 and I take it they come
from the users RID, so to me, that is the way that sssd needs to work,
i.e. a user logging into any client in the domain would get the same
uid, 3000017 for instance. Also S4 winbind does not seem to use slots,
every S4 winbind starts at 3000000, so sssd again needs to be aware of
the workgroup name instead of using a number based on the SID. Setting
up sssd needs to very simple, using different idmap ranges etc is not
simple.
Also, make sure that ldap_idmap_range_min, ldap_idmap_range_max and
ldap_idmap_range_size match their equivalents in winbind. I'm not
certain if they do by default.
See sssd-ad(5) for more details (on SSSD 1.9 and later)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlFnFqsACgkQeiVVYja6o6PmpACfeAf8iO9HMYYkGKU4Nuq9UyRT
etwAnRAxo5ug5AsLlTL+N4LgiUMY3ytp
=4XP6
-----END PGP SIGNATURE-----
_______________________________________________
sssd-users mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
sssd-users mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
