As part of todays hackathon at Univention, I’ve successfully tested LAPS (Local Administrator Password Solution) with an Windows 10 (1903 build 18362.267 with Security Rollup 2019-08) joined to a UCS 4.4-1 (errata234) Samba/AD DC Master. To make this work, two UCR variables need to be set on the DC Master and Samba needs to be restartet after setting them:
ucr set samba4/schema/update/allowed=yes samba/acl_search=yes
/etc/init.d/samba restart ## please note that the Samba services always need to be started with this script
If you have several UCS servers that providing servcies as Samba/AD domaincontroller (i.e. UCS DC Backup and UCS DC Slave system roles), it’s important to run these steps on those too. You can find out all those systems by running this LDAP-Search:
univention-ldapsearch -LLL univentionService="Samba 4" 1.1
The samba4/schema/update/allowed UCR variable is only required on the UCS Samba/AD DC that is holding the FSMO role “Schema Master”. This can be checked simply by running
samba-tool fsmo show | grep SchemaMasterRole
After these preparatory steps, you may follow the steps described in the original LDAP_OperationsGuide provided by Microsoft. As one of the first steps after downloading and installing the LAPS msi, the guide requests you to perform a small Samba/AD Schema update by running a powershell command Update-AdmPwdADSchema from the administrative windows client. After this has been succesfully done, you cane disable schema updates for UCS Samba/AD again by unsetting the UCR variable samba4/schema/update/allowed again like this:
ucr unset samba4/schema/update/allowed
/etc/init.d/samba restart ## please note that the Samba services always need to be started with this script
Please take care to leave the UCR variable samba/acl_search set to yes on all of your UCS Samba/AD DCs at all time. Please also take care to set this variable on all new UCS Samba/AD DCs you install in the future. It may be wise to automate this by configuring a UCR Policy via UMC or UDM (see e.g. Univention Corporate Server).
Note:
Special considerations apply to school servers in UCS@school domains, which all are running separate Samba/AD domains that are just interconnected via UCS OpenLDAP. On the Samba/AD domain level they are not connected to each other (e.g. they don’t replicate via Microsofts DRS LDAP replication protocol with Samba/AD DCs in the central school department), so the Samba/AD schema extension will not automatically affect them. So, please accept my disclaimer at this point: I have not tested this with UCS@school, so I cannot recommend it there yet.
Just a last word of caution: This LAPS technology saves local Administrator passwords as clear text in an Samba/AD LDAP attribute ms-Mcs-AdmPwd at each of the Windows client machine account objects that have been activated for LAPS by the corresponding GPO setting. For security it is absolutely vital that read access to this attribute is restricted to a very narrow number of privileged trusted administrative accounts. I recommend to read the original LDAP_OperationsGuide provided by Microsoft thoroughly and take proper care when setting the Samba/AD LDAP DS-ACLs to control the All extended rights permission and test the effectiveness by checking effective rights for specific users and groups that should not have access. If you choose to fine tune the DS-ACLs note that explicit DS-ACLs set on an machine account take precedence over inherited DS-ACLs set for a parent container or OU. By default all Domain Admins explicitly have Full access to all Windows client machine accounts. Please take the time to first test this in a test lab environment before going out and rolling this out in production.