Aliases only in winbind and then...

[Simo Sorce]

Hello Volker and all samba-techincal fellows,
nice to see finally other people get some time to think about this
issue.
I would like to espose here my view that's the sum of near a year of
toughts about the sam (passdb) system.

NOTE:
If your time is valuable stop here and discard this email ;-)
Ok if you are reading this line I'll warn you, this is a _long_ and
possibily boring mail.
You have been warned! :-)


Now that the limits of the current system shows up it may be the time to
get out again some ideas.

First of all, I think we should get a step back from current programming
and look at the whole picture and take in account a number of factors.

a) we need a system the mimic windows behaviour as close as possible so
that MS System tailored application can work with our PDC.

b) we need to ease as much as possible administration issues for our
user base as the insights of a domain controller are yet compilcated by
itself, requiring our admins to understand the implications of a mixing
of semnathics from win32 to unix is most of the time just too much

c) we need a consistent account database system not splitted over 100
little hacks around the code.


To fullfill point a) we have still a long trip, from PDC<->BDC
synchronization to the support of all kind of accounts type out there,
from wks accounts, to aliases to interdomain trust accounts.
To fullfill point a) I believe we also need point c) or the special
cases will be so much that we will never get it right.

My move at the times of the idmap code was trying to get one of the
pieces right, now I recognize my move was premature but me (and
abartlet) had clear the goals of that initiative and the goals appealed
so much to make us give it a try. I think it is essential to go toward
that line again, but trying to avoid some of the errors we stepped in.

Idmap is central as we can't really do anything but map real unix
account into windows account and in particulare unix uids and gids into
windows sids. And to have the hope of consistency we must do it in a
centralized place. Idmap is this place.

To fullfill point b) we need to clear out many things in samba3 code
base and point c) is a prerequisite. Currently we have accounts split
into 2 system (unix and the backend of choice), then we have group
mapping, and winbind/idmap is yet a separate issue. Backends are not
consistent, so while you have group mappings in ldap when you use tdbsam
you have them in group_mapping.tdb instead of passdb.tdb, and
group_mapping.tdb is used also when you use the text file based
smbpasswd.
When we are a domain server we have again 2 choices: hand made accounts
or use nss_winbind.


Now let's just take a breath and think which would be the perfect SAM.
After the dream, wake up, and look at our techinical and backwards
compatibility constraints.

The perfect passdb/sam backend would store everything from user
accounts, to groups to trust information, and at last also privileges.
Unix accounts simply does not exist as this backend is our system
backend.

Now which are our constraints?

A) We have many platforms with different degrees of support for nss
backends.
B) We have many installations with a great number of them still using
smbpasswd and local system accounts, and that's all for their needs
C) We have many potential system that may be reverted to use samba and
have already all the accounts, groups and file permissions set.

Can we ever have the perfect SAM? Can we have it at least on some
platforms but keep compatibility for the others?

I think the answer is Yes to both questions (ok the first one is
optimistic but we can get quite close :).


What do we need to do?

I think we may have all that with a single passdb API.

The idea is that we should be able to run in a "compatibility mode"
where you have accounts and group provided by the system (wether it is
provided by files, ldap, nis, or any other NON-winbind nss backend is
not relevant). In this mode the passdb still have all accounts and
groups you can see through samba but they are simply a mapping to the
system accounts (Here the group code will be very similar to our current
group mapping, but it will be only a special case of general group
support).

If you have a system capable of nss_winbindd AND the admin wish to use
it at full then you get near the perfect SAM. In this system you can
make any kind of accounts in SAM (users, trusts, groups, aliases, ...)
and winbindd reads from the selected passdb all the needed values, map
the [u,g]id<->sids through idmap and provide the system all users and
groups according to the data found.

This is not an out-out situation we may have various degrees of mixed
full-SAM and compatibilty-mode, mainly to support current installations,
but we should drive ourselves to the perfect SAM where possible as that
will elegantly and greatly solve most of our problems and
inconsistencies, but most important it will help out our user base
giving them a consistent way to manage a samba PDC.


How can we do that?

Ok, one of the steps will be to revive the idmap system so that it
handles all the needed mappings, this code will be responsible for
mapping IDs from all the sources _except_ the "compatibilty-mode" ones
that must have special rules (basically they will use the standard
"fixed alghoritm mapping"). I think we may put all of this in idmap too
(as it will ease a migration to a full sam maintaing all mappings in
place), but we may still argue a bit over there.

Next we need to have group support in passdb, that's not difficult to
do, and that will be done only for tdbsam and ldapsam right now.
NOTE: here I assume smbpasswd,nis and other "lower level" backends will
always run in compatibilty mode.
Mysql, postgresql and other "exhotic" backends will chose what class to
be part by implementing or not winbindd hooks (explained later).

Once we have both account and group support we will add a winbindd API
extension to passdb that is able to provide winbindd privileged access
to the backend information (winbind hooks). This API will assure that
not a single operation ever need any kind of information from the system
(not a single getpw*/getgr* call). I have made an attempt to build such
a system, and it was called winbindd_passdb (No winbindd_rpc won't
work). It' not a difficult task (and I have a good amount of code we can
use), my attempt was blocked by the abesence of group support in passdb.

Why group support in passdb is fundamental?

Don't make the mistake of thinking that it is needed only to help us out
with aliases. No that's not the main point even if that is a very
positive consequence. We need it to have a consistent nss interface.
The problem with nss is that it does not like too much backend mixing ..
you can't have both system accounts and winbindd groups and hope group
listing for users will work correctly. AFAIK you must have both users
and groups in the same nss backend to be consistent.
That's why I propose that "compatibility mode" system should never see
aliases provided through winbind ... even when you provide users.
If you want to have good group support you must switch all to winibind
or nothing.
NOTE: this is really easy for sites that already use ldap, with these
sistes you will simply stop to use nss_ldap and instead will use
nss_winbind. It can be thought as a magic filter beetwen ldap and nss,
as it will make it possible to have aliases.

Ok, here is what I think should be done. We can do much of it with no
much pain.

Comments are very welcome.

Simo.

On Wed, 2004-03-03 at 17:03, Volker.Lendecke at SerNet.DE wrote:
> Hi!
> 
> Having implemented a prototype of aliases that sort of works, I have asked
> myself what it means to have aliases only available when nss_winbind is in
> charge.
> 
> Without nss_winbind the illusion of aliases never worked, although group
> mapping pretended something different. What do we gain by group mapping? From
> my point of view it is a painful replacement for the "domain admin group"
> parameter. Sorry, JF....
> 
> What happens if only winbind is in charge of aliases, and we completely throw
> away the group mapping? 
> 
> When we are not running nss_winbind, we can not support aliases. No way. In
> that case I do not think we need the group mapping in its current form. The SID
> for the domain groups can be generated by algorithmic mapping. 
> 
> What about the vampired non-winbind DC? Here group mapping really helps, but
> here we could use the winbind idmap backend libs directly from within smbd.
> The well-known domain groups (Domain Admins etc) can be put into idmap as well.
> 
> When we are running nss_winbind, we have aliases. Then generating SIDs for our
> domain groups in of /etc/group becomes a bit more difficult. The future
> equivalents of pdb_getgrgid and pdb_getgrnam should ask winbind for a SID which
> it has to invent then.
> 
> A difficult case is winbind without nss_winbind. smbd has a shortcut in the
> session setup where it asks winbind for the groups a user is member of. It is
> to be decided whether we can expand aliases here, as these memberships can not
> be reflected in getent group.
> 
> Managing aliases can be done via the normal winbind fake-group interface. The
> addmember/delmember calls have to take sids in addition to names, but that
> should be it.
> 
> What about the builtin domain? Its members (the WKN_GRP entries) are lost
> without winbind. But as there are currently quite a lot of 3_0 servers running
> in production without having them mapped shows that they are not really
> essential. If anything really breaks for particular calls (lsalookupsids?) we
> could fake them in the non-winbind case.
> 
> How does passdb (in the 2.2 sense) fit into this game? I'm not sure it is
> relevant at all. The only thing I can think of is that everybody creating a
> passdb account should ask winbind for a new SID.
> 
> Hmmmm. Any good argument to stick with group mapping? Any other comment?
> 
> Volker
> 
> P.S: Attached find a little that is a start in that direction. Alias
> memberships are maintained with 'wbinfo -[o|O] SID:Alias'.
-- 
Simo Sorce - simo.sorce at xsec.it
Xsec s.r.l. - http://www.xsec.it
via Garofalo, 39 - 20133 - Milano
mobile: +39 329 328 7702
tel. +39 02 2953 4143 - fax: +39 02 700 442 399