Access manager Configuration query

[Afsars12]

Hi Ryan,

We have installed the access manager service with a certificate and service account. Also done with the Okta configuration and able to access the application.

Given the permissions to the service account to read for the below parameters

1. ms-Mcs-AdmPwd
2. ms-Mcs-AdmPwdExpirationTime

However, getting the below error while trying to retrieve the local admin password. Our old LAPS UI setup retrieves the password for the same machine wherein we get an error in Access manager.

Note: It is only happening to one of the OUs, though we have given service account permissions to all the needed OUs

[ryannewington]

It's definitely a permission issue.

How did you grant permission to read the admpwd atributes? Using our script or the Microsoft PowerShell cmdlets?

Granting read access is not enough, theres a special permission to read confidential attributes that our delegation script from within the app will set for you.

Our full set up guide can be found here https://docs.lithnet.io/ams/configuration/deploying_features/setting-up-microsoft-laps

[Afsars12]

We have granted the permissions through PowerShell cmdlets not through a script, as the script contains commands related to write permissions.

The below cmdlets from the script related to self permissions, I hope we have already given during the initial LAPS setup itself, is this mandatory again?

$propertyAccessRule5 = new-object "System.DirectoryServices.PropertyAccessRule" $selfSid, "Allow", "Write", $msLapsPasswordGuid, "Descendents", $computerObjectGuid $propertyAccessRule6 = new-object "System.DirectoryServices.PropertyAccessRule" $selfSid, "Allow", "Write", $msLapsPasswordExpiryGuid, "Descendents", $computerObjectGuid $propertyAccessRule7 = new-object "System.DirectoryServices.PropertyAccessRule" $selfSid, "Allow", "Read", $msLapsPasswordExpiryGuid, "Descendents", $computerObjectGuid

Also below part of the script contains, extended rights, Please advise are these extended rights are necessary for the solution. Currently, we are able to retrieve the password in some OUs only with the read permissions,

$propertyAccessRule1 = new-object "System.DirectoryServices.PropertyAccessRule" $serviceAccountSid, "Allow", "Read", $msLapsPasswordGuid, "Descendents", $computerObjectGuid $propertyAccessRule2 = new-object "System.DirectoryServices.PropertyAccessRule" $serviceAccountSid, "Allow", "Read", $msLapsPasswordExpiryGuid, "Descendents", $computerObjectGuid $propertyAccessRule3 = new-object "System.DirectoryServices.PropertyAccessRule" $serviceAccountSid, "Allow", "Write", $msLapsPasswordExpiryGuid, "Descendents", $computerObjectGuid $propertyAccessRule4 = new-object "System.DirectoryServices.ActiveDirectoryAccessRule" $serviceAccountSid, "ExtendedRight", "Allow", $msLapsPasswordGuid, "Descendents", $computerObjectGuid

[ryannewington]

Did you use Microsoft's Set-AdmPwdReadPasswordPermission cmdlet or something else?

Read permissions are not enough to read protected LAPS passwords. The extended rights allow read of confidental attributes, which is required for your users. Domain admins have this by default, other users do not. This is how Microsoft protects LAPS passwords, because all users by default have read permission to all attributes in the directory except for those marked confidential.

The script grants permissions for the computers to update their own LAPS password (this is the 'self' permissions you see). If you have granted this already, you dont need these permissions. (It won't matter if you run them, because these exact permissions exist anyway)

The permissions granted to the service account are to read the laps password attribute, read and write the laps expiry date attribute (so access manager can tell workstations that their passwords are expired and they need to rotate them), and the special 'read confidential attributes' extended right.

Microsoft's PowerShell cmdlet does this all for you as well. We set exactly the same permissions as they do.

[Afsars12]

Thanks Ryan,

Yes, We have used Set-AdmPwdReadPasswordPermission cmdlet.

I have one more query, what is your recommendation on giving the permissions to the service account(gmsa)? is it better to give at the OU level or at the domain root level?

If we plan to give at the domain root level, are there any security implications to consider?

[ryannewington]

If there is only one AMS service providing access to LAPS passwords, then doing that the domain level is fine. The only time you'd consider otherwise, is if you wanted AMS only to broker LAPS access to certain OUs/devices and not others.

[Afsars12]

Thanks Ryan