laps
2 TopicsInstalling Windows LAPS over Legacy LAPS
Hi all, I have a simple LAB - of 1 DC and 1 member server (both 2019) which has had legacy LAPS installed (schema extended etc). Now when I installed the MS update on the member server and then tried to run the permission command I got an error saying have you extended the schema. I tried to extend the schema using the new LAPs command but got an exception error. Now I can't find any documentation or info regarding 1 ) In an environment where legacy LAPS has been configured, do you have to extend the schema again? 2) Do you have to run the permission command on the OU so the machines can write to the password attribute? The LAPS has been out for a while so we should have more info.Solved608Views0likes2CommentsEnabling LAPS on Exchange Servers
I have three Exchange 2016 Servers in our on-prem AD environment, and have been in the process of deploying LAPS across our organisation's members servers. Unfortunately, I've been unable to get LAPS to work properly on our Exchange Servers. Or more accurately, I've been unable to get the AD Computer objects, which represent our Exchange Servers, to inherit permissions from their parent OUs. The outcome of this, is that members of our "LAPS Password Readers" security group cannot read the LAPS password stored in AD. Attempts to Mitigate I've gone into the Computer Object representing say MX1. In Security > Advanced, clicked Enable Inheritance. Then it works fine for a short amount of time, before Inheritance is disabled again. I've manually added the Read permission for the ms-Mcs-AdmPwd attribute on the specific MX1 Computer Object. Doesn't work at all, the permission gets wiped straight away. Of course, I've done a bit of research, but have found little evidence to show other people suffering from this same issue. In fact, Reddit users with on-prem Exchange and LAPS users don't appear to have any issues at all. My research into the issue of non-inheritable AD permissions points me towards stuff regarding highly privileged / protected accounts, an adminCount attribute in AD, and SDPROP. All of my Exchange Servers have an adminCount attribute of 1, which I think is because they are indirectly members of BUILTIN\Administrators, through membership of the 'Exchange Trusted Subsystem' group. That is, each server is a member of 'Exchange Trusted Subsystem', and 'Exchange Trusted Subsystem' is a member of BUILTIN\Administrators. A Microsoft Appendix about Protected Accounts & Groups in Active Directory mentions the AdminSDHolder object, which provides the template permissions applied to protected AD objects. Should I add my LAPS Password Readers" security group to the AdminSDHolder object, giving it the necessary permissions to get LAPS working? I'm surprised I've not found any official guidance in the LAPS documents or elsewhere about this tbh... Any advice would be appreciated! Thanks, Alex1.5KViews0likes1Comment