Viewable by the world

TABLE OF CONTENTS

Active Directory Account Creation Policy

Effective March 1, 2021, you must use the AD Management tool to create AD accounts.

Active Directory Account Policy

Account Types

Account TypeAccount PurposeNaming SchemePassword RequirementsAccount Ownership
User Accounts
  • User accounts are used for routine operations, like accessing Windows workstations or network shares.
  • These accounts have no additional domain privileges
  • The user ID must match the employees Berkeley Lab Identity account name
  • example: gahaverkamp
  • 12-month expiration
  • 14-character minimum length
  • Meet complexity requirements
  • There are no exceptions
  • Accounts can only be assigned to Berkeley Lab staff and affiliates.
  • A user may only have one user account
  • The employee ID must be recorded in the attribute field in "employee number"

Privileged Accounts (-sa)

  • Privileged accounts are separate accounts used for managing computers within the same security scope or context
  • Privileged accounts do not have additional rights within Active Directory
  • Must be named the same as the owner’s user account with the -sa extension (example: gahaverkamp-sa)
  • 12-month expiration
  • 14-character minimum length
  • Meet complexity requirements
  • There are no exceptions
  • Privileged Accounts can only be assigned to Berkeley Lab staff and affiliates.
  • The DN of the privileged account will be recorded in owner’s enterprise directory account
  • The Employee ID will NOT be recorded in the attribute field in "employee number" in AD (this violates 1:1 relationship)

AD Accounts (-ad)

  • AD accounts are separate accounts that have additional rights within Active Directory 
  • These account may not be used to log into workstations or other resources
  • AD accounts should only be used on the primary workstation of the AD account owner. 


  • Must be named the same as the owner’s user account with the -ad extension (example: gahaverkamp-ad)


  • 12-month expiration
  • 14-character minimum length
  • Meet complexity requirements
  • There are no exceptions


  • AD Accounts can only be assigned to Berkeley Lab staff and affiliates.
  • The DN of the privileged account will be recorded in owner’s enterprise directory account
  • The Employee ID will NOT be recorded in the attribute field in "employee number" in AD (this violates 1:1 relationship)


Service Accounts
  1. Service Accounts are used by computers and applications to access AD resources.
  2. These accounts are not to be used by humans
  • Names should be PREFIXED with svc-
  • eg: svc-identitymanagement
  • Naming convention exceptions may be required for legacy 
  • 12-month expiration
  • 14-character minimum length
  • Meet complexity requirements
  • There are no exceptions
  • A person can have multiple service accounts
  • A service account can have multiple owners
  • The DN of the service account will be recorded in each owner’s enterprise directory account
  • The Employee ID will NOT be recorded in the attribute field
Managed Service Accounts
  • Managed service accounts are a new type of service accounts best suited for use when the account will be used in a pure Windows environment.
  • These can only be used if the application has been designed to work with this account type.
  • The benefits of msa are:
    • MSA’s use a complex automatically generated password (240 bytes, which is 120 characters, and cryptographically random).
    • The password can only be retrieved by the host(s) associated with the mSA
    • Cannot be locked out
    • Cannot perform interactive logons.
  • Names should be PREFIXED with msa
  • eg: msa-identitymanagement
  • MSA passwords are managed automatically, and are not controlled by users.
  • MSA’s use a complex automatically generated password (240 bytes, which is 120 characters, and cryptographically random).
  • Default password age 30 days, and are changed automatically.
  • A person can have multiple managed service accounts
  • A managed service account can have multiple owners
  • The DN of the managed service account will be recorded in each owner’s enterprise directory account
  • The Employee ID will NOT be recorded in the attribute field in "employee number" in AD (this violates 1:1 relationship)
Test Accounts
  • Test accounts are like user accounts, and have no additional privileges
  • Test accounts are only for use in testing purposes, and are not to be used for routine access of systems or resources.
  • Must be named the same as the owner’s user account with the test extension
  • example: gahaverkamp-test
  • 12-month expiration
  • 14-character minimum length
  • Meet complexity requirements
  • There are no exceptions
  • Test Accounts can only be assigned to Berkeley Lab staff and affiliates.
  • A user may have multiple test accounts in addition to their user account
  • The DN of the test account will be recorded in owner’s enterprise directory account
  • The Employee ID will NOT be recorded in the attribute field in "employee number" in AD (this violates 1:1 relationship)

Account Creation

  • All account creation must go through IDM

    • Although technical controls are not in place to limit people from creating accounts, this can be determined retroactively.  

    • All accounts created by staff outside of IDM will be deactivated immediately.

  • IDM will provide a web-based tool to request new accounts.

    • For the time being, requests should be made by email to help@lbl.gov.

    • Details to follow

Enforcement 

  • Accounts found not adhering to the above requirements are subject to immediate deactivation. In some cases the deactivation is automated and occurs on an ongoing basis.

  • Accounts found with non-expiring passwords will immediately have that setting removed.  There is no notification for this process.

Active Directory Class Object Management Policy

      • User Object Policy

        • This manual action is performed by LBL Help Desk personnel.

        • Upon notification of employee termination - The User object is immediately disabled.

        • User objects will be automatically disabled after 180 days of inactivity.

        • 180 days after the User object is disabled it is moved to the Aged_Accounts OU.

          • This automated action is managed by LBL Active Directory domain administration.

      • Computer Object Policy

        • Upon retirement of ODS PCs - The Computer object is deleted from the LBL domain.

            • This manual action is performed by LBL Active Directory domain administration.

        • 180 days after a Computer object has last communicated with the LBL Active Directory it is disabled and moved to the Aged_Accounts OU .

            • This automated action is managed by LBL Active Directory domain administration.

      •  Contingency for Class Object Policy

        • For objects where no notification of employee termination exits - The object is automatically disabled (after 365 days of non use) and moved to the Aged_Accounts OU.

          • This automated action is performed by LBL Active Directory domain administration.

        • For Computer Objects that were not actively retired. 365 days after the Computer object is disabled it is deleted from the LBL Active Directory.

          • This action is performed by LBL Active Directory domain administration.

Active Directory Base Object Creation Policy

      • User Object Creation Policy

        • The User Object name must be unique within the LBL domain. The AD User Object name should match the employees Berkeley Lab Identity account name.
        • On occasions where an employee returns to LBL and they no longer have an AD User Object one can be created for them by creating a "Help Ticket" for the LBL Help Desk.

      • Computer Object Creation Policy

        • The LBL forest consists of a single domain, and all computer accounts in the same domain must have a unique name. A computer name cannot be used if it has already been assigned to another computer in the LBL domain.
        • Computer Objects should not be created before adding a Computer to the LBL AD as this is not always a reliable way to perform this action.
        • Computers and therefore Computer Objects may be added to the LBL AD by any valid User Object (up to a limit of 10 Computer Objects).
        • Computer addition in excess of 10 Objects requires user membership in the "AddComputers" AD security group.

        • Computer Objects should follow the proper naming convention.

  • No labels

Was this site useful for you? Do you have any feedback or suggestions? Please click here to send your comments about this FAQ to IT.