modification of userAccountControl according to MS-SAMR 3.1.1.8.1.

[Matthias Dieter Wallnöfer]

Well, the related code part located in samldb.c line 920 is as follows:
>                         /* Step 1.5: Add additional flags when needed */
>                         if ((user_account_control & UF_NORMAL_ACCOUNT) &&
>                             (ldb_request_get_control(ac->req, 
> LDB_CONTROL_RELAX_OID) == NULL)) {
>                                 user_account_control |= UF_ACCOUNTDISABLE;
>                                 user_account_control |= UF_PASSWD_NOTREQD;
>
>                                 ret = samdb_msg_set_uint(ldb, ac->msg, 
> ac->msg,
>                                                          
> "userAccountControl",
>                                                          
> user_account_control);
>                                 if (ret != LDB_SUCCESS) {
>                                         return ret;
>                                 }
>                         }
Okay, you both Anatoliy and Kamen speak about the UF_ACCOUNTDISABLE 
flag. Now the next interesting question: and the UF_PASSWD_NOTREQD flag? 
Is this also not added if "userAccountControl" is specified on add 
operations?

Cheers,
Matthias


Kamen Mazdrashki wrote:
> On Thu, Jan 13, 2011 at 00:04, Andrew Bartlett<abartlet at samba.org>  wrote:
>    
>> On Wed, 2011-01-12 at 23:42 +0200, Anatoliy Atanasov wrote:
>>      
>>> Hi Matthias,
>>>
>>> Kamen and I stumbled upon a code that modifies the userAccountControl attribute of a user object, when it shouldn't.
>>> We noticed that when you add a user with userAccountControl 66080 it ends up with 66082, which means that the account is disabled.
>>>        
>> Isn't this what Windows does?
>>      
> Yes, when userAccountControl is not supplied on add.
>
>    
>>      
>>> The code modifies the userAccountControl of a user that is being added to the database and the documentation regarding the change of that attribute states:
>>> "If the value of the userAccountControl attribute _in_the_database_ contains a bit that is specified in the following table, the userAccountControl attribute MUST be updated with the corresponding bit(s) using a bitwise OR."
>>>
>>> The add operation is still an originating update, but in this case the attribute isn't in the database and shouldn't be modified.
>>>
>>> Do you agree to change it?
>>>        
>> I'm rather confused, can you please give an example where Windows does
>> not disable the account on add?
>>      
> We are working on this example :)
>
>    
>> Is this based just on a reading of the docs, or a specific test?  If
>> it's a test, can you give some more detail on what you have tested?
>>
>>      
> This is based on what we were observing while testing our internal tool.
> Account created is disabled on Samba, but not disabled on w2k3-r2.
>
> ----------------------------------------------------------------------------
> I am writing here after testing it and it proofs we have a bug in Samba.
> I've used this simple record for creating a user record:
>   {'dn': 'CN=test_736,CN=Users,DC=samba,DC=devel',
>    'objectClass': 'user',
>    'userAccountControl': '66080',
>    'sAMAccountName': 'test_736'}
>
> Against w2k8-r2 after adding the record,  userAccountControl = '66080'
> Against Samba4 after adding the record, userAccountControl = '66082'
>
> So I think Anatoliy's statement holds true and we have a bug.
> I will work on Samba implementation to come with a patch, if
> Matthias is ok with this?
>
>
>