UCS with Samba4 and different password policy for some users

UCS - Univention Corporate Server
#1

Hi to everyone. This is my first post at this forum.
I am trying to set-up an AD environment based on Samba4 (USC 4.0-3) with different password policy for at least two groups of users running Windows workstations. When I set global password rule in: LDAP directory/samba/{domain-name}/Password it works perfect (I mean enforcing password change), but created password policy applied to some users directly, or to container containing some users seems not working at all (even if I force group policy update from user account on workstation).
The USC manual isn’t sufficiently clear on differentiate password policy, so the most important information I need to get is: is it possible to apply different password policies within UCS AD environment?

Maciej

#2

Generally assigning policies to containers should work. There’s normal inheritance in play: policies assigned directly to a user will trump all overs, and from there on all containers up to the root are checked. The first object for which a policy is found stops the process.

You can verify which policies are in effect for a particular user with the command line tool »univention-policy-result« (example of how to run it: »univention-policy-result -D uid=administrator,cn=users,$(ucr get ldap/base) -W uid=mbunkus,cn=users,$(ucr get ldap/base)«).

For example, I have a user called mbunkus. There’s a global policy regarding passwords, it’s called »cn=default-settings,cn=pwhistory,cn=users,cn=policies,dc=mbu-test,dc=intranet«, and by default this is assigned to the root of the LDAP tree.

If I change the policy for e.g. the container object for all the users (cn=users) to a policy called »cn=safe-passwords,cn=policies,dc=mbu-test,dc=intranet« and execute the tool I get these results (shortened to the relevant part):

[code][0 root@master ~] univention-policy-result -D uid=administrator,cn=users,$(ucr get ldap/base) -W uid=mbunkus,cn=users,$(ucr get ldap/base)
Enter LDAP Password:
DN: uid=mbunkus,cn=users,dc=mbu-test,dc=intranet

POLICY uid=mbunkus,cn=users,dc=mbu-test,dc=intranet

…

Policy: cn=safe-passwords,cn=policies,dc=mbu-test,dc=intranet
Attribute: univentionPWHistoryLen
Value: 3

Policy: cn=safe-passwords,cn=policies,dc=mbu-test,dc=intranet
Attribute: univentionPWExpiryInterval
Value: 30

Policy: cn=safe-passwords,cn=policies,dc=mbu-test,dc=intranet
Attribute: univentionPWLength
Value: 16

Policy: cn=safe-passwords,cn=policies,dc=mbu-test,dc=intranet
Attribute: univentionPWQualityCheck
Value: TRUE[/code]

So what you should do is:

[ol][li]Check the user object with the aforementioned »univention-policy-result«.[/li]
[li]If step 1 shows policies you would not expect then verify each LDAP tree node from the user object on up to the root node to see where policies are assigned and where they’re set to inherited (UMC: domain → LDAP directory → right-click on a node, select »edit« → [Policies]).[/li][/ol]

#3

Policies should work but in my case they don’t seem to work. I tested it in some environment and (after they didn’t start to work) I configured UCS from the scratch and have the same situation. Using recommended tool »univention-policy-result« I am able to see applied policies for specific user (by applying to container ‘users’), but when it comes to enforce policy settings … there is no adequate action - I mean password change is not enforced on defined period, when I initiate password change from user account - password length in not enforced, etc.
I am able to check some aspect of password policy using commandline from within Windows machine: net user /domain, and password expiry parameter also indicates, that only global domain password settings are applied to users.
The only idea I have is to force password change on next logon for specific users with command issued with scheduled task.

Maciej

#4

Hey,

I’ve just received note from Univention that this is a limitation of the current Samba version. The way I’ve described should work if it weren’t for this limitation. There are bug entries open in the Bugzilla for this already; see 38748 and 38749.

Mastodon