[Samba] Problem with Universal Groups
Trimble, Ronald D
With many thank to Jerry, my cross domain authentication is now
working. This leads to a new problem. I cannot get samba to
authenticate a remote domain user in a Universal group to authenticate
properly.
Here are the details:
USTR-LINUX-1:~ # wbinfo --name-to-sid=NA\\USTR-LINUX-1-REDHAT-READ
S-1-5-21-725345543-2052111302-527237240-349134 Domain Group (2)
USTR-LINUX-1:~ # wbinfo --name-to-sid=EU\\inblr-auth1
S-1-5-21-606747145-879983540-1177238915-173280 User (1)
USTR-LINUX-1:~ # wbinfo
--user-domgroups=S-1-5-21-606747145-879983540-1177238915-173280
S-1-5-21-606747145-879983540-1177238915-513
.
.
.
S-1-5-21-606747145-879983540-1177238915-79634
S-1-5-21-606747145-879983540-1177238915-79966
S-1-5-21-725345543-2052111302-527237240-349134 **Here is the group!!**
S-1-5-21-725345543-2052111302-527237240-177738
S-1-5-21-725345543-2052111302-527237240-349185
S-1-5-21-725345543-2052111302-527237240-307510
S-1-5-21-725345543-2052111302-527237240-177742
S-1-5-21-606747145-879983540-1177238915-90389
S-1-5-21-606747145-879983540-1177238915-72164
S-1-5-21-606747145-879983540-1177238915-91149
S-1-5-21-606747145-879983540-1177238915-70785
S-1-5-21-606747145-879983540-1177238915-91412
However, when I try to set up a test web page to
require group "NA\USTR-LINUX-1-REDHAT-READ"
And then attempt to access the page, I get the following error:
error] [client 192.63.xxx.xxx] GROUP: EU\\inblr-auth1 not in required
group(s).
Does anyone else have something like this working? What am I doing
wrong?
Thanks,
Ron
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
Don Meyer
winbind will only show group membership for users in the same domain
as the group. We are seeing the same mis-behavior here. Group
members from other domains are simply not being enumerated by winbind
as a group member (getent group), even though the other-domain user
itself is properly listed (getent passwd).
I tried to report this as a bug, but it was closed/reopened as a
feature request. Discussion was left that I had to prove that the
other-domain user can successfully connect to a resource with
permissions mapped directly to that other-domain user, but fails to
connect to the same resource when permissions are mapped to a domain
local group in the local server's domain that contains the
other-domain user. (I have yet to create this test-case because of
unrelated time-constraints...)
Cheers,
-D
Don Meyer <dlm...@uiuc.edu>
Network Manager, ACES Academic Computing Facility
Technical System Manager, ACES TeleNet System
UIUC College of ACES, Information Technology and Communication Services
"They that can give up essential liberty to obtain a little
temporary safety,
deserve neither liberty or safety." -- Benjamin Franklin, 1759
Trimble, Ronald D
bug. I could easily provide all of the diagnostics since I have it set
up like this right now.
The strange thing is, I can get it to work with Domain Global groups,
but not Universal groups which shows the SID properly. Domain Local
doesn't work at all unless the user is in the same domain as the group.
How do we get this escalated?
Don Meyer
MS documentation indicated that other-domain users were not valid
within Universal/Global groups, but were in a Domain Local Group.
As far as trying to at least get Domain Local group handling fixed in
winbind, I would suggest looking at Bug 3530 on
bugzilla.samba.org. The more people that can show similar failure
cases, the more likely we can convince them that this is a bug that
needs fixing, and not a "feature request".
Cheers,
-D
Gerald (Jerry) Carter
Hash: SHA1
Don Meyer wrote:
> I can't speak for Domain Universal/Global groups -- our read of the MS
> documentation indicated that other-domain users were not valid within
> Universal/Global groups, but were in a Domain Local Group.
>
> As far as trying to at least get Domain Local group handling fixed in
> winbind, I would suggest looking at Bug 3530 on bugzilla.samba.org.
> The more people that can show similar failure cases, the more likely we
> can convince them that this is a bug that needs fixing, and not a
> "feature request".
Don,
Please allow me to clarify. We are not ignoring this class of
bugs. We are simply saying that the issue is harder to fix that
people realize. It's not an issue of making enough noise
for us to realize that there is a problem. Volker already
acknowledged that. So rather than treating it as a simple bug
to be fixed, we are trying to deal with the larger set of issues
surrounding it. Thanks for being patient.
cheers, jerry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFECQj8IR7qMdg1EfYRAot6AKDlqK7sk7b1MBk9rVy4MqreZ1CPnACgw5uD
Ubv+sfVN1UOuM9iskyRrfB4=
=Brqb
-----END PGP SIGNATURE-----
Don Meyer
>Don Meyer wrote:
> > As far as trying to at least get Domain Local group handling fixed in
> > winbind, I would suggest looking at Bug 3530 on bugzilla.samba.org.
> > The more people that can show similar failure cases, the more likely we
> > can convince them that this is a bug that needs fixing, and not a
> > "feature request".
>
>Don,
>
>Please allow me to clarify. We are not ignoring this class of
>bugs. We are simply saying that the issue is harder to fix that
>people realize. It's not an issue of making enough noise
>for us to realize that there is a problem. Volker already
>acknowledged that. So rather than treating it as a simple bug
>to be fixed, we are trying to deal with the larger set of issues
>surrounding it. Thanks for being patient.
Jerry,
I don't think the issue is patience. Perhaps you (the samba team)
have your own meaning assigned to each level in the system -- perhaps
"feature enhancement" means something more to you internally than it
does to us on the outside.
To me, the inconsistency between what the group membership reported
via winbind and via the net command, alone, would be enough to rate a
"bug" in ay of the development projects I am involved with. My
original severity rating as "major" was intended to indicate the
level of impact this problem is having in our implementation, for
lack of anything else to base the initial severity rating on.
When someone then gets told "closed - won't fix this", that is seen
as a dismissal. ("Go away, find another solution...") When one is
told that this is not a bug, but a feature enhancement, this too is
seen as a dismissal -- albeit to a slightly lesser degree. From the
outside looking in, it appears that the team does not recognize this
as a problem.
If instead the response was: "yes, this inconsistency is a problem
(bug) -- the causes however, are particularly insidious, and will
take some major reworking and the fixing of contributory problems
before we can properly address this. This is going to take a while,
so don't expect any progress on this soon." This would have been
closer to the point I think you are trying to make...
Also, documenting this as a known limitation in the interim might be
helpful -- especially to others designing systems around Samba with
the expectation that winbind group handling is the same as in W2K(3)...
Cheers,
-D
Don Meyer <dlm...@uiuc.edu>
Network Manager, ACES Academic Computing Facility
Technical System Manager, ACES TeleNet Conferencing System
Technical Lead, ACES Web Infrastructure
UIUC College of ACES, Information Technology and Communication Services
"They that can give up essential liberty to obtain a little
temporary safety,
deserve neither liberty or safety." -- Benjamin Franklin, 1759
--
Gerald (Jerry) Carter
Hash: SHA1
Don Meyer wrote:
> If instead the response was: "yes, this inconsistency is a
> problem (bug) -- the causes however, are particularly insidious,
> and will take some major reworking and the fixing of contributory
> problems before we can properly address this.
Don.
So we all agree it was a breakdown in communication. Volker
is working with Ronald and has already sent a briefly written
patch to try to address some of the domain local group issues.
Quite frequently it takes several days worth of email to come
to a consensus on what the proper behavior should be and if
everyone has a solid understanding on how it actually works in
Windows.
cheers, jerry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEDHXBIR7qMdg1EfYRAqh7AKDrJeUOt5RIjHMGpvFpDC+cZkpU0wCgru21
jfrZY0c/nRFgxnkhiY8cCuE=
=Cyeh
-----END PGP SIGNATURE-----