Op 28-10-2023 om 14:21 schreef Rowland Penny via samba:> On Sat, 28 Oct 2023 13:50:31 +0200
> Kees van Vloten via samba <samba at lists.samba.org> wrote:
>
>>>> I consider this a big security omission: if? Samba is the
source of
>>>> information but not the the authenticator of the user, that
>>>> application cannot block expired users !
>>> But, Samba when running as an AD DC is the source of information
AND
>>> the source of authentication. A user with an expired password will
>>> not be allowed to logon.
>> You are right, this is preferable, but not always the case.
>>
>> For example Samba does not support? MFA, an application that does
>> this can use Samba as its user database but has to perform the MFA
>> authentication with its own mechanism.
>>
>> The situation I have is that you can login with MFA (from internet)
>> while you are blocked with normal authentication (when in the office)
>> when your password is expired. That is definitely not alright!
> It isn't, but I would say that is a failing in the MFA rather than
> Samba AD.
Not really, there is no way you can make an LDAP filter to see that an
account is expired. Samba simply does not provide that information in a
form that can be used in an application filter (which is the same a
single ldapsearch command).
Your suggestion below to have 'ms-DS-User-Password-Expired' would solve
the whole issue and so does setting bit-23 in 'userAccountControl'.
But both are not implemented yet, i.e. for the time being a workaround
is required for this piece of functionality. That brings me back to the
plan of making a small cron-script for this purpose.
To prevent a potential race condition with Samba updating something in
'userAccountControl' and the cron-script as well, it might be a better
idea to use another user attribute, for example the nowadays obscure
'primaryTelexNumber ' and set it to 'expired=true'.? With that
the issue
is solved, the LDAP query to check for a user that can be allowed to
login would be:
'(&(objectCategory=person)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(!(primaryTelexNumber=*expired=true*)))'
Using asterisks around 'expired=true' allows for other string to be
added to this attribute, would there be the need for it.
This is non-intrusive, it can be simply removed when Samba acquires the
real functionality.
What about the other question: for testing purposes it would be so handy
to be able to set expiry on an account by hand. What would be an easy
way to do that?? I would think an ldbmodify, but what would be the
modification?
- Kees.
>>>> How to proceed from here?
>>>>
>>>> I guess the real fix to update 'userAccountControl'
and/or
>>>> 'accountExpires' need changes in Samba's C code. In
the meantime I
>>>> would like to close this gap, so I am tempted to write a
>>>> cron-script to check expiry and then update
'userAccountControl'
>>>> every minute or so.
>>>>
>>>> Any other thoughts?
>>> I am not sure if Unix can use 'userAccountControl' and even
if it
>>> can,
>> You can, I used it in the past to set 512 / 514 for enabled /
>> disabled account.
> I was actually referring to the password expired part.
>
>> Now I am using samba-tool for it because that is
>> easier with a bit-field (because other values than 512/ 514 can be
>> there and you just want to toggle bit-1 (the 2), which would make the
>> code a bit complexer).
>>
>> As an alternative the cron-script you set / reset some value in
>> another (used) attribute, which can then be used in queries.
>>
>>> you are still going to need a script to check if it contains
>>> '8388608'.
>> This is easy, there is a special LDAP function to query bit-values,
>> the same as for account disabled:
>>
>> (!(userAccountControl:1.2.840.113556.1.4.803:=2)) # for not disabled
>>
>> (!(userAccountControl:1.2.840.113556.1.4.803:=8388608)) # for not
>> expired
> I always forget those, good job someone knows what they are doing ;-)
>
> What would be better is if Samba could be made to understand
> 'ms-DS-User-Password-Expired'
>
> Rowland
>