"algorithmic rid base" bogus?

[Volker Lendecke]

Hi!

What was 'algorithmic rid base' originally made for? If I remember it correctly
it was designed to support migrated domains in a sane way. The idea was to
migrate users from an existing domain, look for the largest RID and set the
'algorithmic rid base' just above that. So new users and groups would not
interfere with the migrated ones.

Why is algorithmic id mapping necessary at all? It was a correct fix for the
problem that the initial smbpasswd file did not contain a proper RID field.

Recently I added S-1-22-1-<uid> for Users and S-1-22-2-<gid> for groups. What
does this mean? uid2sid and gid2sid always return something that actually helps
for querying the secdesc on a file. It is displayed correctly.

There's a caveat that I just found out one step later however: The
samr_query_usergroups call can't return anything sensible if the groups a user
is member of are not mapped. The primary group sid is fine, this is stored with
the SAM_ACCOUNT structure, but the additional groups are lost. This might be
important as this influences the token we're returning in the SamLogon call.
People might have (from my point of view invalidly) set workstation security
descriptors based on non-explicitly-mapped groups.  Question: Is this really an
issue? If I pursue my plan further I might have to create a compatibility
option just for this call to automagically create the group mapping entries
based on the algorithm.

The other area where algorithmic ID mapping helps is the creation of new users,
groups and aliases. New users and groups right now are created by calling the
appropriate scripts, and the RID assigned is taken from the algorithm. In times
where we have the allocate_rid operation this is bogus I think. The only
problem is that allocate_rid only works if winbind is around. The deeper bug is
that allocate_rid is part of the idmap API. This is the wrong place, it is a
passdb property.

So assuming we always have allocate_rid available, we can dump two smb.conf
options: 'enable rid algorithm' and 'algorithmic rid base'.

'enable rid algorithm' is a property of the passdb backend chosen. smbpasswd
has it, the others don't.

'algorithmic rid base' not needed anymore. With smbpasswd you can't migrate
domains anyway, so there is no point in leaving space above 1000. tdb and ldap
both have a proper allocate_rid function where the next rid to be allocated can
be chosen when net rpc vampire is done.

Thinking about migration issues right now, but I think the only real issue is
generating the samlogon token, and this is either doable on the fly or even
better it is scriptable. Enumerate all users, do the query_usergroups call for
them and add explicit mapping entries.

Volker

P.S.: I wonder how many attempts it will take to finally get this sane
*including* migration from current (broken) setups...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20051227/b3ea7247/attachment.bin