Security Identifier (SID) to User Identifier (uid) ResolutionSystem

Nicolas Williams Nicolas.Williams at wdr.com
Thu Dec 30 16:03:03 GMT 1999


[NOTE: Again, replying to a mail from the archive; who can change the
web archive to include mail message IDs?]

Leslie M. Barstow III (phoenix at faerealm.com) wrote:
> I think we're not as far out of agreement here as it looks: 

You're right, there really is little disagreement.

Making Samba optionally use an API to a guid<->sid mapping system would
be very simple and easy to maintain.

Jeremy believes that ppl who use this will have a very hard time keeping
their databases synchronized. This is probably true for some (most?) of
the ppl who would like to use this new feature, but it's not true for
ALL such ppl.

Luke insists that the current behaviour is bad. IT IS NOT. It's just
looks bad because when one tries to look at and manipulate ACLs on Unix
files on SMB clients via Samba fileservers one will see user/group names
that are qualified as being local to the Samba server REGARDLESS of any
REAL EQUIVALENCY there might actually be between the NT user and it's
Unix persona.

That's it. Now, add to Samba the damn interface to SURS and let ppl play
with SURS outside the scope of Samba. It's no big deal and I bet will
lead to much progress in related ares (PAM_NTDOM, NSS_LDAP, NSS_AD, XAD,
what you've all been calling windbind, etc...)

And that's the end of the argument.

> * tables vs. algorithms: Samba can generate outgoing (PDC) SIDs by 
>   algorithm. Inbound, it currently uses usernames. This *could* be 
>   strengthened with the Domain authentication code returning a SID - 
>   different users with the same username on different domains could 
>   confuse this, as could re-using names on the same domain. A table-based 
>   solution would ensure we got the right one. 

True. I hadn't thought about this.

>   (note: this scenario shows poor advance planning, but sometimes that's 
>    the only planning you get - departments and companies merge...) 

I work at a Bank. We've been through a merger a year, on average. It's
not easy. The business usually doesn't know or care much about technical
issues (NOR SHOULD THEY): they just want IT to do their part in the
merger. I think SURS would be a tool that one could use in such a
situation (though not necessarily the tool one would choose - often it's
best to bite the bullet and cleanup the conflicts and so on - sometimes
the business will keep two environments running in parallel and leave
the true integration work for much later - I've seen both of these
approaches).

> * table code: doesn't need to be maintained in Samba; it can be a seperate 
>   library. Personally, I think it could go into libsmb without being 
>   much of a maintenance drain, but it's not necessary. 

Right.

> * winbind: Samba *could* use winbind to do it's uid resolution, but 
>   needs to pass a full "needs to pass a full "user at domain" name to
>   ensure proper identification. 
>   I'm not sure all systems' getpwnam() functions are up to handling long 
>   names, though. Also, this does not lock out name re-use, and NT 
>   encourages it by doing all authentication based on SID (not 
>   name) - Samba has the right info, Winbind wouldn't. Also, Winbind 
>   should be using a table lookup to prevent confusion in complex 
>   configurations. 

A getXXXbyYYY() interface is needed that does not hide SIDs.

Actually, a generic interface to user credentials (POSIX, NT, whatever)
is needed. This might then generate interest in kernels supporting more
than one type of credential for processes and, eventually, for files.

After all, the use of cred structs in many *nix kernels was done to make
credentials more opaque to various areas of kernel code. Let's further
this trend.

> * SURS table maintenance: Jeremy has a good point here. It needs to be 
>   updated reliably by programs accessing this interface (the api itself 
>   does not show a need for accessing NT to validate these items - it 
>   only stores the information. Another program would seem to be 
>   responsible for maintaining the table. 

Jeremy wants SURS to be outside the scope of Samba. If that's to be so
(I second Jeremy on that one, actually), then the issue of maintenance
of multiple databases that have information in common should ALSO be
outside the scope of Samba. This is not an uncommon problem, or rocket
science either.

> * A real solution: Is going to be a long time coming. PAM offers the 
>   ability to set tickets, and XFS can set arbitrary attribute fields, 
>   but the rest of the system calls and compatability just aren't there. 

Actually, PAM needs to be extended so there's way to pass in
forwardable/proxiable Kerberos tickets.

> --
> Leslie M. Barstow III  | http://www.faerealm.com/phoenix
> phoenix at faerealm.com   |    Linux and Apple][GS links:    computers/
> PGP key at www.pgp.com |    Fight junk e-mail abuse!:     computers/spam/
> Wow!  It all fits.     |

This thread is getting long and hard to follow.

:)

Nico

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.



More information about the samba-technical mailing list