Hiya Adam,
> Thanks again.
You're welcome - sorry I don't seem to be being much help :-(
> We would love to move to RPCSEC_GSS KRB5 based authorization for NFS - but
that in itself is a major project. I looked at this thoroughly 8 years ago
(and had it functionally working, long before Linux even had NFSv4)
It's (fortunately, 'cause it really needed it ...) substantially
been improved:
> but it was not really operationally viable for certain reasons (such as i)
unattended operations needing automatic ticket renewal past the final expiry
time which requires keytab stores for such accounts with password rollover
processes etc, ii) session based credentials caches as used with ticket
forwarding,
Since "Solaris 10" (I believe that's what you're using from your
other post?) 6/06, that's (theoretically ...) all handled for you by
"ktkt_warnd".
I.e., somewhat since your last looking at it - might be worth a
quick look at again, depending on how up-to-date your "Solaris 10" boxes
are, of course ... And "ktkt_warnd" may not know what's needed, depending
on how your Samba Kerberos interacts with the system Kerberos - it's more
designed for maintenance of tickets issued as the result of interactive
logins - but it might be worth a quick play around with just to see ...
> iii) and the NFS id mapping and gsscred system was far from operationally
viable). This may have improved a little since I looked at it before but I
suspect not too much so would need hundreds of many days work for myself to
code operational solutions.
Hopefully not - "ktkt_warnd" should already (hopefully) be able to
do most of what you'd need to code, and the NFS id mapping/GSS/... system
does seem to work properly, or at least acceptably, now. We use it
ourselves for NFS mounting some filesystems from "Server 2008 R2" boxes, and
all the ID mapping actually works correctly (much to my surprise - Soracle
playing nicely with Microsoft?! ...).
> Actually Kerberos/GSSAPI/SSPI is an area I am (dare I say it) quite expert
and I have Samba configured in a way which is as much as possible using only
Kerberos (via dedicated keytab etc, only the annoying secrets.tdb computer
password store prevents it from being a "proper" Kerberos implementation).
I have used Centrify too, btw.
> As for ACLs - I am afraid they are required! Again because of the 16 group
limitation!!!!! If all file objects use owner GID access control only then
you end up with many separate "groups" of accounts needing to be in that
resource group which implies also a user ends up being in many many groups.
Yes, that could be a problem, unless you can use something other
than AUTH_SYS ...
However, if the ACL is being applied at the point of access (Samba),
based on the AD groups, then it is less of a problem anyway. You're not
worrying about group access being passed over-the-wire for NFS, because it's
Samba that's applying the constructed ACL based on the AD group membership
(*and* any underlying filesystem permissions, but if Samba is the only point
of access then that's not a problem anyway).
I.e., if Samba is the only way by which the ACLs need to be applied
to the NFS mounted filesystem, it shouldn't matter whether NFS is handling
the groups correctly because it's never having to. The only group
authentication presented over NFS will be the primary group; because it's
the primary group, that will always be in the NFS group list anyway (it's
the supplementary groups that overflow the 16 group limit).
Now if you're needing to regulate access for other points of access
as well (E.g., local processes) then that doesn't necessarily work; if it's
just via Samba then it should work regardless (though remember to recompile
Samba if you change the kernel group limit or it will all core-dump on you
...).
> Actually in the most part I find they work very well, and Samba almost
behaves correctly these days when evaluating them - the only issue I have
seen is with directory defaults as Samba decides to manage file creation ACL
inheritance itself rather than allowing OS posix ACL defaults to be applied
(eg. issue with insecure execute bit being applied to newly created files
because this is required for newly created directories to allow change dir
access etc).
Particularly with Samba, it all gets horrendously more complex
because of mapping DOS attributes onto permissions bits (as you're obviously
aware), which can leave you with some extremely strange permissions being
set at the filesystem level and all sorts of headaches. E.g., as you
mention, execute bits being applied to newly created files ...
If you're not mapping DOS attributes through Samba then it's all
much simpler and more predictable.
Still don't like the little perishers though! :-)
> Essentially you have to imagine the groups we see evaluated via Samba user
context will be identical as those for a UNIX login for the same user - it
is completely unified. That is all except for the UNIX PGID!!!
Heh!
> Regarding posting my questions in the technical group I thought this was
not allowed for non-samba developers, otherwise both of my current queries
would already have been sent there.
You have to request membership; as I understand it, if you're seen
to be asking questions which need to be in the technical group then that
will be granted.
Or at least that's how I understand it, and that's how it's worked
for me (I've got a couple of conversations going on at the moment, with some
extremely helpful Samba developers, regarding decoding Kerberos PACs in
particular ...).
Request membership and see what happens :-)
> Adam
Tris.
-----Original Message-----
From: Tris Mabbs [mailto:tm-samba201...@firstgrade.co.uk]
Sent: 06 September 2013 10:15
To: Burgess, Adam
Cc: samba@lists.samba.org
Subject: RE: [Samba] primary GID based access for user in 16 supplementary
groups
Hiya Adam,
> We have not seen any issue with primary group not matching
> file/directory
group owner - but I will look out for this in future.
Yes, it was a bit of an obscure one to track down, and I'm still not
convinced I've got to the bottom of it - we have a working solution now and
that's where I had to stop poking around. Thought I'd mention it though in
case it applied in your case.
> We are using NFSv4 but as I understood it this still uses AUTH_SYS
authentication method by default and this is what prevents us moving to >16
groups. ...
Well yes, and no.
Using AUTH_SYS will trip the 16 group limit problem, yes. That's part of
the definition for NFS defined in RFC<something I can't remember> - that's
where the 16 group limit comes from and it's not tuneable.
Were you to be using Linux, there's a "magic" hack which gets around this,
by ignoring the group list supplied by NFS and looking up the membership for
itself. Haven't played with it myself, but I believe (anecdotally) that it
works well. However that's absolutely no use whatsoever to you in a Solaris
environment!
Where NFSv4 *does* score over the earlier versions is that you have *other*
authentication methods available - you don't have to use AUTH_SYS. In
particular, as you're integrating all this with AD for unified identity
management, there are going to be Kerberos tickets floating around the place
and you could potentially use AUTH_KRB5 instead. Bingo - problem gone. OK,
so nothing in computing is ever quite that simple, but get AUTH_KRB5 working
and "Bingo - problem gone". So that might be a solution for you to this
problem, and potentially simplify your account management as well.
> Essentially our problem generally revolves around ACLs that gives
> access
to objects for a given group ...
Eurgh - stop right there.
ACLs - work of The Devil! :-)
Potentially ACLs are going to cause you major headaches on NFS mounts anyway
- "The wonderful thing about standards is that there's so many to choose
from"; NFS ACLs are supposed to be able to be mapped to and fro versus the
underlying filesystem (whatever ACL mechanism that's using); personally I've
never had ACLs work correctly on NFS shares of pretty much any underlying
filesystem, and also be mapped correctly on the client end. I've also not
seen ACLs work consistently and reliably with Samba (and I believe there
were a couple of recent threads on that exact subject in the support fora,
but don't quote me on that ...).
Now, since you're accessing this using Samba, and Samba works out group
membership based on the AD groups and uses that primarily to control access,
effectively merged with the local filesystem permissions (as I understand it
- I'm not a Samba guru and could be wrong ...), you might have more luck
achieving the equivalent of group-based ACLs by nested group membership in
the AD groups.
As you're using "Quest", I don't know how well that would work - I'm afraid
I've heard of "Quest" but never used it (just Samba/native OS support for AD
integration, oh and "Centrify" ...). However I don't see why it *wouldn't*
work.
So where you use "setfacl" ("Set F*ck-All", as I tend to think of it ...
Pardon the language - really NOT a fan of ACLs, so many issues ...) to
permit group write to a directory, and one of the groups happens to be
users' primary GID; instead define an AD group ("(Unix) Access 'xxxx'
resource", or some similarly descriptive name) with however Quest assigns a
GID to that group, then set the group ownership on the objects to the GID of
that group, then include in that group all the other groups to which you're
currently granting access via ACLs.
E.g.:
/someshare/controlled_resource:
ACLs:
Grant R/W access to groups:
users1
users2
...
Instead:
Create AD group "(Unix) Access 'controlled_resource'",
Assign (say) GID 10000 to that group,
chgrp 10000 /someshare/controlled_resource
chmod g=rwx,g+s /someshare/controlled_resource
Include "users1", "users2", ... in that group.
Same effect, no ACLs, Samba should be happy. You might need to tweak the
file/directory creation modes masks for Samba, and be careful of the effects
of mapping system (etc.) attributes (which are mapped using Unix permissions
bits), but get the right combination of Samba options and that should work.
If I've understood correctly what you're trying to achieve, that is ...
Of course, nesting groups like that may simplify, or may make more complex,
your group membership issues, but that's not a problem anyway if you move to
AUTH_KRB5 ...
As for your IDMAP cacheing issue - yes, I saw that :-) IMHO you might not
get a response in this group about that - it looked like a "bit" (ha!) more
of an in-depth technical issue and, if you get no responses here, you might
need to put it into the samba-technical forum - in my experience, the Samba
developers are extremely good about monitoring this forum for issues, but
there tends to be so much traffic in here (asked by users and can be
answered by other users) that more complex technical questions can
occasionally get overlooked.
Hope that helps, and good luck!
Cheers,
Tris.
-----Original Message-----
...
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
