[Samba] Domain password policy with Samba AD DC

[Peter Milesson]

On 29.08.2023 21:38, Andrew Bartlett via samba wrote:
> On Tue, 2023-08-29 at 12:58 +0200, Peter Milesson via samba wrote:
>> On 27.08.2023 23:45, Andrew Bartlett wrote:
>>> On Sat, 2023-08-26 at 11:49 +0200, Peter Milesson via samba wrote:
>>>> Hi folks,
>>>> I just wonder why it is not possible to set domain password
>>>> policieswith GPO, using the Windows RSAT Group Policy Manager?
>>>> For mostothersettings, using GPOs through RSAT works.
>>>> For somebody who sets up a Samba AD DC infrequently, this is a
>>>> hugetrap. There should be a very visible warning on the AD DC
>>>> setup wikipage, that you *must* setup password policies with
>>>> samba-tool, ifyouplan to change the default password policies
>>>> (which I assume mostwilldo). It should also be very clearly noted
>>>> that it is not possible todothis with RSAT (as lots of people
>>>> will try that anyway). Thiswarningshould also be displayed on the
>>>> Group Policy wiki page. If there areother GPO policies that can
>>>> not be set with RSAT, those should alsobelisted.
>>> Thanks Peter for reaching out on this,
>>> So, the challenge is that in the past, Samba didn't know how to
>>> readthese, and the settings were just ignored.
>>> Now it can, but given there are now existing domains, which
>>> settingshould be primary, the one in the DB or the one in the GPO?
>>> That is why the smb.conf setting "apply group policies" needs to be
>>> setto Yes if the GPO approach is to be taken.
>>> Feel free to ask for a wiki account to point out this if you feel
>>> itwould be helpful.
>>> Andrew Bartlett
>>>
>> Hi folks,
>> I've tried to get password policies setting using the Windows GPMC
>> from RSAT working. Unfortunately, no change. It just does not work.
>> Here is the smb.conf for the AD DC:
>> # Global parameters[global]         dns forwarder = 78.110.208.34
>>          netbios name = TESTADC1         realm = TESTDOM.TALPS
>> server role = active directory domain controller         workgroup =
>> TESTDOM         idmap_ldb:use rfc2307 = yes         apply group
>> policies = yes
>> [sysvol]         path = /var/lib/samba/sysvol         read only = No
>> [netlogon]         path = /var/lib/samba/sysvol/testdom.talps/scripts
>>          read only = No
>> The only way to set password policies for the domain, still seems to
>> be through samba-tool domain passwordsettings and the parameter
>> "apply group policies" has got no effect at all.
>> If I create a gpresult.html file on a Windows member PC, it shows the
>> settings I have set with the Windows Group Policy Management Editor
>> (GPME), but when setting a password for a user in Active Directory
>> Users and Computers, the settings are not honored.
>> In GPME there is also the folder Samba\smb.conf, where the different
>> password policy parameters can be set. No effect at all.
>> In practice, this is not a big deal. You probably set the domain
>> password policies once, and forget about it.
>> I'm not going to waste more time on this. Just use samba-tool domain
>> passwordsettings for setting password policies, and forget about
>> GPMC.
> I would also note that the even better password polices - fine grained
> password policies - (password setting objects) were never available via
> GPMC and were always directly set to the directory.
> We have good tooling for that in samba-tool, plus whatever windows uses
> would edit the same LDAP attributes.
> Andrew Bartlett
>
Hi Andrew,

Thanks for the information. In my setting, standard password policies 
are sufficient.

Is it possible to set password policies at all using GPMC from RSAT? I 
did not succeed, as I wrote. It's not an important issue, however it 
would have been nice to be able to use one tool for everything. In a 
small setting like mine (about 40 users), I just set it once with 
samba-tool, and that's it. I would be very surprised if the need ever 
arises to change something there. I would sooner expect that there will 
be requirements for other types of authentication that are more secure 
in the not so far future.

Best regards,

Peter