In Active Roles track who views LAPS password

In Active Roles is there a way to track who can view the LAPS password attribute? We were looking way to audit who views the attribute ms-Mcs-AdmPwd. 

Parents
  • Hello, whitet10.

    There is no "out-of-the-box" feature to track this yet, but it is certainly within the realm of accessible configuration. Attached is a video demonstrating one possible means by which to implement this kind of solution. Hope you find it helpful!

    Cheers,
    Shawn.

  • This is an interesting solution, but I see some drawbacks. The primary issue is that it is client-specific. This solution will only work in the Active Roles Web Interface.

    So, to break it down: currently. Active Roles does not log anything when an Initiator views any attribute. Active Roles only logs modifications. So, we should therefore turn a view into a modification, and then audit this abstraction.

    Create a unstored custom Virtual Attribute and a Change Workflow triggered by a view of the LAPS Password attribute. Add in a "Modify Requested Changes" activity and then write some value to the unstored custom Virtual Attribute. If you make the attribute a Directory String syntax, you could even write the samAccountName of the Initiator to that Virtual Attribute value. It doesn't matter that it's unstored: the value written will still be saved in the Active Roles Change History.

    This would be a client-agnostic solution, and wouldn't interfere with any existing Active Roles functionality.

Reply
  • This is an interesting solution, but I see some drawbacks. The primary issue is that it is client-specific. This solution will only work in the Active Roles Web Interface.

    So, to break it down: currently. Active Roles does not log anything when an Initiator views any attribute. Active Roles only logs modifications. So, we should therefore turn a view into a modification, and then audit this abstraction.

    Create a unstored custom Virtual Attribute and a Change Workflow triggered by a view of the LAPS Password attribute. Add in a "Modify Requested Changes" activity and then write some value to the unstored custom Virtual Attribute. If you make the attribute a Directory String syntax, you could even write the samAccountName of the Initiator to that Virtual Attribute value. It doesn't matter that it's unstored: the value written will still be saved in the Active Roles Change History.

    This would be a client-agnostic solution, and wouldn't interfere with any existing Active Roles functionality.

Children