hi,
is there a way to use laps in ucs?
https://technet.microsoft.com/en-us/mt227395.aspx
Thx!
Erik
happy new year everyone… does someone else tried to use laps?
Hey,
After your initial question I had tried to install it in my test environment. However, I wasn’t even able to get it to install on Windows correctly — meaning that after installing it on a Windows 7 machine and starting PowerShell, all I got were some error messages when trying to execute the PowerShell commandlets that’re supposed to install the ActiveDirectory extensions. Therefore I cannot really say whether or not this is supposed to work.
The client-side portion is easy enough and shouldn’t a pose a problem. It’s just a small installer providing group policy stuff. Nothing fancy there. What I do see as a potential problem is the AD schema extension. It’s not that you cannot extend the AD schema used by Samba; the process is described here for using SCCM, for example. However, the way that LAPS does it is by calling some PowerShell commandlets that’re supposed to connect to the AD server and extend the schema there. I don’t know (and haven’t found any documentation) whether or not that is supported by Samba (this is more of an issue with Samba 4, not with Univention Corporate Server).
Kind regards
mosu
yes exaktly… so we need to wait until samba will support laps correctly?
I don’t know. Like I said, I wasn’t actually able to get PowerShell to even start the commandlets — and that part didn’t have anything to do with Samba yet. Therefore I cannot answer your question.
i think this ps commandlets are only executable in a windows server (as active directory server) to extend the ad schema… so is it not possible to extrend the sabma ad schema manualy?
That’s possible, though I had hoped that the commandlets would be executable on any domain-joined machine and that they’d do their work over the net.
In general it is possible to extend Samba’s AD schema, but that’s a manual process (see e.g. the article about integrating SCCM with Univention) that I’ve already linked to above).
FYI, you can use LAPS. See https://lists.samba.org/archive/samba/2018-November/219543.html
You have to extend the schema using samba, so the directions provided by Microsoft for AD won’t work. Powershell doesn’t work for Samba configuration. The client side stuff will work. And the Group Policy stuff should work using RSAT.
Hi, I think LAPS is a good solution and would like to introduce it in my company. To be honest, I find it too difficult to do so with such little amount of documentation. I would really appreciate it, if someone could write a bit on how to implement it with UCS and Samba. Thanks!
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. http://docs.software-univention.de/manual-4.4.html#central:policies).
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.
3 Likes
Hi, is this solution still working or an updated version available? I ask because this post is from 08/2019 and we use UCS 5.