This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Should ADSAccounts used as Service Accounts have an IdM Employee record in the Person table?

What is best practice for managing Service Accounts?  We want to assign accountablility, attest and report on all User Account types in IdM but we are only creating Employee records in the Person table for users who come through our HR system.  What is the best approach for managing Service Accounts in IdM?  Should ALL Accounts have Employee profiles?  Also, what about Exchange mailbox system accounts that have ADSAccounts.  These are all showing up in our report for ADSAccounts that do not have an Employee profile.

Parents
  • Hello,

    Any answer you are given will be more opinion than a globally applicable best practice, and obviously depend on many factors. Service accounts, like any other set of credentials, should be managed such that the right person or process has the correct access to the correct resource at the appropriate time, and that this access is properly audited and attested. In addition, appropriate controls are in place, with the mitigation necessary to address any SOD (Separation of Duty) or other considerations.

    So, this has to be analyzed in the context of who controls the IDM system and is it appropriate that these individuals and groups have the given control over the service accounts. In addition, it is necessary to determine what rights the service account has and consider who controls the application or service that operates under this context.

    So, now an opinion on a best practice, both for IDM and the overall governance automated process credentials:

    1) Use SPN's where possible
    2) Remediate what can be corrected or controlled
    3) Mitigate through automated processes and notifications as much as possible - this is something Q1IDM can do well
    4) Inject the IDM team into the review or any applications entitlements based on these credentials
    5) Use OU's and groups to aggregate and imbue entitlement
    6) Explore managed vs unmanged account behaviors control service ac lifecycle
    7) Consider what rights a service needs startup vs normal operations

    I hope this helps- I understand it is very high level. Without specifics, is hard to put forth an optimal solution.

    All the Best,

    Paul

Reply
  • Hello,

    Any answer you are given will be more opinion than a globally applicable best practice, and obviously depend on many factors. Service accounts, like any other set of credentials, should be managed such that the right person or process has the correct access to the correct resource at the appropriate time, and that this access is properly audited and attested. In addition, appropriate controls are in place, with the mitigation necessary to address any SOD (Separation of Duty) or other considerations.

    So, this has to be analyzed in the context of who controls the IDM system and is it appropriate that these individuals and groups have the given control over the service accounts. In addition, it is necessary to determine what rights the service account has and consider who controls the application or service that operates under this context.

    So, now an opinion on a best practice, both for IDM and the overall governance automated process credentials:

    1) Use SPN's where possible
    2) Remediate what can be corrected or controlled
    3) Mitigate through automated processes and notifications as much as possible - this is something Q1IDM can do well
    4) Inject the IDM team into the review or any applications entitlements based on these credentials
    5) Use OU's and groups to aggregate and imbue entitlement
    6) Explore managed vs unmanged account behaviors control service ac lifecycle
    7) Consider what rights a service needs startup vs normal operations

    I hope this helps- I understand it is very high level. Without specifics, is hard to put forth an optimal solution.

    All the Best,

    Paul

Children
No Data