Perhaps the easiest way is to enable successful login auditing on your domain controllers, then search through the logs for the user you're looking for.
Couple side notes:
- Service accounts should have some sort of logical structure to their name. Microsoft recommends the format Vendor$Product$Server. So if you have Acme's FooBar running on Server01, then the service account name should be Acme$FooBar$Server01.
- You should keep track of all your service accounts, and where they are used. This can easily be a simple spreadsheet (Google Docs, LibreOffice, whatever are all free). At a minimum it should keep track of the account names, intended use, last password change, and the servers/services that use them.
- Passwords should be incredibly long an complex, I use a KeePass to generate 32 letter "goop". This way the password doesn't need to be changed as often. Changing passwords guards against a few things, none of which should readily apply to a service account with a good password.
- You should review your business practices on a regular basis to ensure they aren't causing more trouble than they're worth. Practices should be justified, most of which are easy.
Terminology:
- A "service account" is any user account, could be the "Administrator" account or any other, which is being used by an process that automatically logs in (most commonly services running on server, hence the name).
- Active Directory is the system that keeps the user accounts, including passwords. It does not run as a user, the accounts are not used "within" it. The accounts are used by other programs.
- Windows has no "root" account. There is a "Administrator" account that was setup when AD was first configured, but it's not special in the way that "root" is special on *nix environments. This "Administrator" account can be completely replaced with relative easy in Windows.
ответ дан
3 December 2019 в 21:37
Ссылка