Peace, To answer my own question/post, I seem to have found the culprit. It looks like it is indeed something very simple, and I could even blame it on the AD ( more or less)...
:o) The userAccountControl attribute is a structure that contains flags pertaining to the user account: (See http://www.selfadsi.org /ads-attributes/user-userAccountControl.htm) As the AD guys on request set the attribute to 33554432 it was actually set to 33554432+512 making the account a normal user UF_NORMAL_ACCOUNT with the UF_NO_AUTH_DATA_REQUIRED flags set. And that explains the lost of TRUST. Solution: The join used to set it to: 69632 (4096 (UF_WORKSTATION_TRUST_ACCOUNT) + 65536 (UF_DONT_EXPIRE_PASSWD)) So knowing all this: the value needs to be set to 33624064. The original join value + the 33554432 (UF_NO_AUTH_DATA_REQUIRED). Simple. -- \\\// ( o o ) +-------------------------oooO--(_)--Oooo--------------------------+ | Pascal Kolijn "First Snow, Then Silence. | | This Thousand Dollar Screen Dies | | [email protected] So Beautifully." | | .oooO -- Error Messages in Haiku | +--------------------------( )---Oooo.---------------------------+ \ ( ( ) UC IT - EC(L) \_) ) / T:(020)(59)85385 (_/ http://www.vu.nl/e-maildisclaimer -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
