Thomas Bork wrote:
after "net rpc vampire" migration:
uidNumber: 22693
sambaSID: S-1-5-21-1139895982-289624505-398547282-4370
after the maschine rejoined the domain:
uidNumber: 22694
sambaSID: S-1-5-21-1139895982-289624505-398547282-46388
Hi Christoph, nice to read you :)
Hi Tom, :-)
thanks for your quick answer.
What shows
testparm -sv 2>/dev/null | grep 'algorithmic rid'
?
Think it will look like 'algorithmic rid base = 1000'
because 22694 * 2 + 1000 = 46388
Indeed - it's 1000.
You have to find the point in the migration process, where the new
sambaSID is calculated. Your migrated sambaSID is not correct.
Hmmm... if I understood the "net rpc vampire" migration magic right, the
SID is not calculated using the algorithm you explained above but fetched
from the NT server. (Otherwise it wouldn't be possible to have some SIDs
with uneven RIDs like "....-1933" after the migration.)
What *is* "calculated" during the migration is the uidNumber, and therefore
this may differ from the original one, but does samba really use the
algorithimic relationship between the uidNumber and the SID/RID as a kind
of authentication base for the maschine?
I changed the RID to "2 x uidNumber + 1000", but this didn't solve the problem.
I guess that there's something wrong with the password related attributes
of the maschine account. Do you know where I can find a documentation for
the DC/client trust mechanism?
Christoph
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
