This is the most comprehensive list of Active Directory Management Tips online.
In this article, I will share my tips on, AD design, naming conventions, automation, AD cleanup, monitoring, Active Directory user management, and much more.
Check it out:
1. Active Directory OU Structure Best Practices
If you don’t have a good Active Directory organization unit (OU) design you’re going to have problems.
First, I’ll quickly explain the three main reasons why good OU design is so important.
- Reason #1 Group Policies – Having a good OU design will make implementing and managing group policies much easier. I’ve seen a drastic decrease in issues with proper OU design.
- Reason #2 Delegate permissions – Being able to delegate rights at a granular level and auditing those rights is a must. A proper OU structure will allow you to easily delegate permissions at a granular level.
- Reason #3 Administrative tasks – Modifying user accounts, using LDAP queries, reporting, and bulk changes are all common administrative tasks. If Active Directory is a mess, these simple day-to-day tasks can become difficult for the whole team.
Now that I’ve explained why OU design is so important, let me show you my tips for good OU design.
OU Best Practice #1: Separate Users and Computers
Do not put users and computers into the same OU, this is a Microsoft best practice.
Instead, create a new OU for Users and an OU for computers.
Next, create sub-OUs for each department or grouping.
Do this for both computers and users.
Next, create OUs for specific functions or grouping of similar objects. Here are some examples that I use:
- Conference room computers
- VDI (Virtual desktops)
- Test computers
- Generic accounts
- Service Accounts
I’ll create an OU for each one of these functions.
You can structure the sub-OUs in any way you like, it basically comes down to how you plan to manage the users and computers. In organizations I’ve worked at, it made the most sense to manage them by department and specific functions. The most important tip is to group user and computer objects into separate organizational units.
Active Directory Design Best Practices Example
Here is a real-world example of how a good OU structure makes managing Active Directory easier.
A customer had a domain policy that locks the computers after 15 minutes of inactivity. This policy was applying to every computer in the domain.
This became a problem for conference room computers, users would be teaching or giving a presentation and the screen would keep locking.
To fix this I just created a sub-OU called conference room computers and moved the affected computers into this OU. I created a new Group Policy object that changed the lockout time to 60 minutes and applied it to this new OU.
Now, these computers still inherit the policies from their parent while applying the new timeout policy.
OU Best Practice #2: Create an OU for Security Groups
At first, I put security groups into department folders.
It made sense at the time.
BUT….I was wrong.
What happened was, I would have groups that were not department specific. Where do those go?
They would end up in various places and then no one could find them.
To fix this mess I created a group just for security groups.
Just like users and computers, I can create sub-OUs to group them by department or function.
This works great, I know exactly where all the groups are and can organize them any way I want with sub-OUs. For example, if I or someone on my team needed to give a user access to a shared folder, I would know these groups are in the Shared Folders OU.
OU Best Practice #3: Create an OU for Servers
You want to keep your servers in their own OU. You will have group policies that need to apply only to servers and not workstations and vice versa. I can also create sub-OUs to group specific servers for whatever need.
Now I can apply policies to all the servers or specific ones.
Active Directory structure and design are very important. If you implement the design tips above it will make managing Active Directory much easier. You will have the flexibility to apply group policies, delegate control, and administer AD objects.
2. Use a Standardize Naming Convention
No matter if your organization is big or small you need to standardize the naming of Active Directory objects.
Here are my tips for good naming conventions.
The most popular option is users first initial + last name.
I’ll use “Joe Smith” as an example.
The user name would be: jsmith
The next popular option is complete first name + last name (use a special character to separate the name).
The user name would be: joe.smith
Both methods work well and are user friendly. The one problem you may run into is duplicate user names.
To fix this just add in the middle initial.
For example, I have Joe Smith, then I get a new employee with the name of Jane Smith. The user name for Jane will be the same as Joe so I need to use Jane’s middle initial.
Jane’s middle initial is A, so the username would be jasmith. or jane.a.smith
I would avoid naming conventions that truncate names or include numbers. It’s just too confusing for everyone.
Here is my template for creating groups.
Department or group + resource + Permissions
Let me break this down
- Department or group – You can use the full department name or an abbreviation. It some cases it may not be a specific department it may be users from various departments so just come up with a name for this group.
- Resource – This should define what the group is being used for, it could be one word or a few words (separate words with a hyphen)
- Group Prefix: When you create a group you must select a group type, I use a prefix to define what group I’m using.
- Domain local = L
- Global = G
- Universal = U
- Permissions – The permissions will you apply to the resource
- R = Read only
- RW = Read, write
Here are some examples
Example 1 – Helpdesk staff needs rights to reset passwords.
Security group name would be: Helpdesk-PasswordReset-G
Example 2 – HR department needs training folder locked down
Security Group name: HR-Training-Folder-G-RW
Example 3 – Sales department want shared calendar locked down
Security group name: Sales-Shared-Calendar-G-RW
Once I got all my groups renamed following this naming convention it made it much easier to find and use them.
Computers, Servers, and other AD Objects
For most other objects I follow this naming convention:
Type + department or location code + asset#
- W = Workstation
- L = Laptop
- P = Printer
- S = Server
- V= VDI or virtual machine
- Department: Use two letter appreciations for departments or use a location code
- HR = Human Resources
- MR = Marketing
- SA = Sales
Here are some examples
Workstation in the IT department asset# 1234
Laptop in the HR department asset# 1235
Printer in the sale department asset # 1233
Create a clear naming convention that the whole team can follow, and I’m not just talking about users and computers. Create a naming convention for all objects
3. Monitor Active Directory with Premium Tools
Active Directory is the heart of the network, if it stops beating then everything else dies.
I know FREE tools are great (I use plenty of them) but when it comes to monitoring I rely on professional tools.
It saves me serious time and it provides other IT staff with easy to read metrics on servers and applications.
Here are a few favorites:
SolarWinds Server & Application Monitor – I like this tool as it allows me to monitor any application on any server. Monitors all the components and services that make Active Directory run. If Active Directory is having issues or is slow this program will quickly identify the issue.
SolarWinds Network Performance Monitor – Excellent tool for monitoring the network, bandwidth, CPU, Memory, and many more metrics on any device that supports SNMP.
Netfort Languardian – This is a deep packet inspection program that monitors the network and user activity. Although it may be considered a networking tool it has tons of use cases. I can find out who deleted a file, monitor DNS, find rogue DNS servers, monitor bandwidth to servers and active directory, and much more.
ManageEngine Audit Plus – Provides real time auditing to Active Directory. Track changes to AD objects, user activity, DNS, GPO, and more.
There are plenty of professional tools on the market, I recommend you search around and find what best fits your needs.
4. Use Core Servers (When possible)
Server Core has a smaller footprint, is more secure, and doesn’t require as many updates.
Bonus benefit fewer reboots!
I was skeptical at first when Microsoft said this is the preferred install option. But after running core servers for a few years they ROCK. They are stable, and they really do have fewer updates.
Unfortunately, they don’t work in every situation.
Not all 3rd party applications support core servers.
They work great for Windows servers such as domain controllers, DHCP, DNS.
So, install core servers when you can and reap the benefits.
Here is a nice table that summarized the benefits of server core
5. Know How to Check AD Health
Issues with domain controllers, DNS, and replication are going to cause all kinds of problems.
Here are some quick tips for checking the health of Active Directory.
Use dcdiag to check domain controllers
Dcdiag is a command line tool that analyzes the state of domain controllers in a forest or enterprise and reports any problems. It is built into most Windows server operating systems, it is also included if you have the ADDS or ADLDS role installed.
Use the following command to analyze the health of your domain controllers.
dcdiag /s:servername /a
This will run several tests on various components and services that run on a domain controller.
You will get a fail on any tested that does not pass.
Use dcdiag to test DNS
Use the command below to test dns
dcdiag /test:dns /s:servername
You can in the screenshot the test has detected some issues with my dns
Looking through the tests I’m missing some A and SRV DNS records
Use repadmin to test replication
Use the following repadmin command to test replication between your domain controllers.
6. Use Security Groups to Apply Permissions to Resources
DO NOT use individual accounts to apply permissions on resources (printers, shared folders, applications, calendars, etc).
Instead, use security groups.
This makes adding and removing users to resources much easier. It also helps with reporting and audits.
Once the groups are set up on the resources you don’t have to go to each resource every time to modify access. You just update the group.
Using the group naming convention from tip# 3 this works like a charm.
Here is an example.
I have a folder called training in the sales department.
I will create a group called HR-Training-SG-RW (This following my naming convention tips#)
Then I’ll add this group to the permissions on this folder.
Now anytime I want to give permissions or revoke a user’s rights to this folder I just modify the members of this group.
I can use the method for all resources.
7. Cleanup Active Directory (at least once a month)
Over time, Active Directory will have stale users, computers, and group accounts.
To keep Active Directory secure and tidy you need to find these stale accounts and remove them.
It is recommended check AD at least once a month for inactive computers and inactive user accounts. There are plenty of scripts and GUI tools available that help with finding and removing old accounts.
I have some cleanup tools available on my ad tools page
I run this cleanup process once a month.
8. Add Descriptions to Active Directory Objects
It’s frustrating to see objects in Active Directory and have no idea what they are for.
Even if you are using a good naming convention I still like to add descriptions to objects. Obviously not all objects, but servers, groups, service accounts, and generic accounts I put descriptions on them.
Not only does this help me quickly identify the use of the object it helps the whole team understand.
You can see in the screenshots below I’ve added descriptions to some groups and service accounts.
Here are some non standard accounts, again using the description field I can easily see in Active Directory what these are for.
Again, I don’t do this for all objects, mainly groups, servers, and non standard accounts.
It’s another big time saver.
9. Use Delegation Control Wizard to Set Permissions for non admins (helpdesk)
Active Directory delegation is important to understand so that permissions can be granted without adding users to privileged groups like Domain admins.
Using delegated permissions, you can use the least privileged access method. (Give only rights that are needed)
This helps with security and compliance.
Here are a few examples of why you would need to delegate rights.
- Helpdesk needs to reset passwords
- Update user account info such as phone number or address
- Give rights to add and remove computers from domains.
- Create, delete and manage user accounts
- Modify group membership
In this video, I will give our helpdesk group the rights to reset passwords.
10. Audit Changes to Active Directory
Active Directory auditing is the process of logging changes and events in Active Directory.
Auditing is important for security and compliance reasons.
You should at least be auditing active directory for the following events:
- Failed logon attempts
- Any changes to objects
- Successful logons
- Modifications to Privilege Accounts
- Group Policy Changes
- File/Folder deletes
Before you can audit Active Directory, you must first set up an audit policy.
Steps to audit Active Directory
Step 1: Enable auditing on the domain controller
Step 2: Enable events to audit
Step 3: Review and maintain the audit logs
The above steps are a high level overview.
For detailed steps check out these resources:
11. Track Down the Source of Account Lockouts
Random account lockouts are not only frustrating to the end users but for helpdesk and the admin who is troubleshooting it.
Knowing how to track down the source of account lockouts is something all systems admins need to know.
Mobile devices and user accounts set to run a service are the most common reasons for account lockouts.
12. Automate Common Active Directory Tasks
I would encourage you to automate anything that you can.
Active directory administration involves many routine tasks such as user account creations, modifications, account removals, computer management, security, and so on. Some of these day to day tasks are very time consuming.
Most routine tasks can be automated to make you more efficient at your job.
Here are some common tasks that you should automate:
- User account creation
- Account removal
- Account modifications
- Group Membership Management
- AD cleanup
- File copies, directory cleanups
- Software deployment
- Windows and 3rd party patches
- Decommission of assets
It may be difficult to automate the entire process of some tasks but automate what you can. Automating any part of a repetitive task will save time.
PowerShell is a tool for automating a lot of these tasks.
My team recently automated the whole user account creation process using PowerShell. This involved many steps such as creating the account, adding to groups, creating an office 365 mailbox and creating a personal shared folder.
Creating user accounts has never been easier.
13. Understand LDAP Distinguished Name Paths
Active Directory is an LDAP (Lightweight directory access protocol) directory service, this means all access to objects occurs through LDAP.
LDAP uses paths to locate objects, a full path of an object is defined by its distinguished name.
When integrating other systems with Active Directory it often requires some LDAP information.
Unfortunately, every program does this differently. Having a little knowledge of distinguished paths will help with integrating other systems with Active Directory.
In most cases you need the distinguished name for the following:
- Domain name
- User account (That has read access to AD)
- OU where users are located
Here is how you find the distinguished name
Step 1: Open ADUC and browse to the account
Step 2: Right click on the account and select properties
Step 3: Select Attribute editor
Step 4: Find the attribute distinguished Name, then click the view button
The distinguished name for the user Pam Smith is:
CN=Pam Smith,OU=Accounting,OU=ADPRO Users,DC=ad,DC=activedirectorypro,DC=com
Repeat these steps for any other object that is needed.
14. Use Service Accounts (with least privileges)
There will be a time when you need to run a task, script or program with a user account (domain or local).
These are referred to as service accounts.
First of all, don’t use a domain admin account or any other user account for these.
Instead, create a new account to use for each specific service. Your user accounts should have a policy to change their password every x days. If an account is being used and its password changes that service is going to stop working.
Here are some additional tips:
- Use a descriptive name
- Document the account and add a description in Active Directory
- Create long complex passwords
- Set account to never expire
- Restrict what the account can log into
- Audit and monitor service accounts usage
- When possible create local service accounts instead of domain accounts
- Give the service account the least privileges
- Don’t use one account for multiple services.
15. Delegate Tasks When You Can
No, I’m not talking about delegating rights to helpdesk.
Over the years the responsibilities of System and network administrators have skyrocketed. Some system administrators are responsible for almost everything from the server down to a printer.
To save your sanity be willing to delegate some tasks to others outside of your team.
I was hesitant about this for years. I worked hard to get everything in order, procedures down, and keep systems running 24/7.
BUT as responsibilities grew it reached a point where productivity was down. New projects were slow to roll out.
To resolve this, I learned that it was OK to delegate tasks outside of my team.
Here are a few tasks that I delegated:
- Account setups and removal
- Managing Print Servers
- Modifying Account attributes
- Adding and removing domain computers
- Software distribution
- Modifying group members
- Patching workstations
Talk to supervisors, talk to other staff members that are willing to take on these roles.
If it doesn’t work out simply revoke their rights and take the task back over (I’ve had to do this a few times).
16. Use Restrictive Groups to Control Local Groups
Restricted groups allow you to centrally manage who is a member of local groups on workstations and servers.
One common use of this is to add an Active Directory group into the local administrator’s group on all computers. This is an easy way to give your helpdesk or other IT staff admin rights on all the workstations.
It’s also a great way to prevent users or other staff from adding users to the local admin group.
Regular users should not have admin rights, I’ve seen this get way out of control. You can use restricted groups to put a stop to this.
Here is a video tutorial demonstrating adding a domain group into the local administration’s group on domain joined computers.
Here are some good resources and tutorials on using restrictive groups
17. Get Your Domain Time Right
Why should you care about the time?
If the time is not synchronized on all domain controllers, member servers, and machines you will encounter problems.
So how do you set the time correctly?
Here are a few Time sync tips
1 Set your PDC emulator to a time source
w32tm /config /manualpeerlist:timeserver /syncfromflags:manual /reliable:yes /update
All domain join machines will get its time from the PDC.
2 Disable time synchronization between the host system and guest operating systems.
VMs tend to synchronize time with the hosts (VMware or Hyper-v). It’s best practice to disable this so domain joined systems will continue to use the domain hierarchy for time synchronization.
I remember fighting time issues until we figured out the VMware hosts were changing time and getting out of sync or the PDC.
You may read about setting time with Group Policy. Unless you have jacked around with the time settings on computers you don’t need this.
Domain joined computers will by default sync with the PDC.
18. Document Active Directory & Group Policy
Active directory is critical to authenticating users, authorized access to many resources such as email, printers, files, remote access, and much more.
So, it would make sense to document Active Directory.
Here are a few things that I’d recommend you document
- Forest name
- Domain name
- NetBIOS name
- Forest Functional Level
- All domains in the forest
- Global Catalog servers
- FSMO role holders
- Diagram of topology
- Sites and subnets
- Naming convention for all objects
- Group policy objects and description of what they do
The Microsoft Active Directory Topology Diagrammer is a handy little tool that helps with documentation.
19. Properly Implement Group Policies
I love group policy.
It’s an easy way to control and apply settings on all domain joined computers.
It can even be used to deploy software.
To be successful with group policy you need to follow a few rules.
Here are my group policy tips.
Tip#1 First of all, don’t modify the default domain policy
Tip#2 Do not modify the default domain controller policy
Tip#3 use good OU structure
Tip#4 Do not set Group Policy objects at the domain level
Tip#5 Apply Group Policy at an OU root level
See my complete list of Group Policy Best Practices
20. Implement Change Control
Changes to Active Directory and group policy can disrupt services and affect business operations.
It’s important to put these changes through a change control process to avoid any downtime.
It’s also helpful to document your changes in case something goes wrong, and you need to roll back the changes.
When making critical changes I recommend the following.
- Who is responsible for the change
- Description of the change
- Time of implementation
- Duration of change
- Expected impact
- Has changed been tested
- Backup procedures
I would advise making the change process as simple as possible. Nothing slows progress down more than a bunch of red tape and paperwork.
21. Use Active Directory as Your Centralized Authentication Source for Everything.
If you’re on-premise or cloud-based applications that support Active Directory Authentication, then use it.
It makes authorizations and access to resources so much easier when it’s controlled centrally by Active Directory.
It’s also a huge plus for the end users, they can authenticate with just one username and password.
Any questions? Leave a comment below.
45 thoughts on “21 Effective Active Directory Management Tips”
It’s a very very good tutorial. Thanks !
I would like your advice.
In our company we have this OU design but it is not good for us.
We range computers by city and not office
Domain > City 1 > Office 1 > Users
Domain > City 1 > Office 2 > Users
Domain > City 1 > Computers
We have 60 city and we add city frequently. 1 -3 per years. Each city can have multiple office.
Your advice is to have :
Domain > Computers > City1
Domain > Computers > City2
Domain > Users > City1 > Office 1
Domain > Users > City1 > Office 2
Computers and users will not the default OU
Yes that would work, I would definitely separate the users and computers into their own OUs.
Depending on how you need to apply group policies you can also organize it like so.
Domain > Computers > Department
Then under department and another OU for each City.
Domain > Computers > Department > City1
Domain > Computers > Department > City 2
Then you can apply policies based on department.
Hope that helps.
Nice tips – thanks!
Question/comment on #6: We’ve been exploring (and are a good ways into implementing) Role-Based Access Control and using AD groups to facilitate. As the number of resources that AD groups need to be created for increases, it is resulting in transitive membership to a large number of AD groups for some staff. The resulting security tokens are so large now that it exceeds the http header size limit when trying to authenticate to some internal web apps/sites.
Do you have any insight or feedback on this aspect of using AD groups to implement RBAC? I love the idea, but we’re hitting what appear to be practical limits. (And we have MANY more resources that we were planning to secure this way…)
You are probably nesting groups, is that correct? You should be fine up to 1000 groups.
Yes, we are nesting groups. 1000 is the number we were anticipating based on research, but a few staff (mainly administrators that are in many groups) are at ~375 right now (total transitive membership), and those individuals appear to be consistently busting http header size limits for web apps utilizing Kerberos. Using Fiddler to examine, we’re confirming the header size limit is being exceeded in these cases.
Did a little research on token bloat and the common solution is to reduce a users group membership.
This technet article has a few ideas worth checking out. There is a link towards the bottom for dealing with HTTP and header too long errors.
To reduce group membership take a look at Dynamic Access Control, this gives you the ability to grant access based on user or computer attributes.
I would like to appreciate you for such a hard work and sharing it freely for beginners like me to catch up with your years of hard work, its indeed a detailed description thank you very much!!!
Isreal, no problem.
Excellent work! This is the best checklist I have seen and certainly It comes with many years of extensive experience. You solved my biggest worry about AD knowledge transfer to commence soon. Thanks a ton.
I’ve been an administrator of Active Directory for over 15 years and I’m still learning new things.
very nice tutorial and I have a question, in point 5, which command did you used to know where were the missing entries at the DNS server?
dcdiag /test:dns /s:servername
Had to post a comment as this is just……. WOW!
Thanks very much for this great article. I wish to know how to organize my OUs to prevent lnternet access to machines in a department that shouldn’t have access to Internet. Thanks
A web filter/proxy server is the best way to control internet access. You could use group policy and the windows firewall to block the browsers from running but its an all or nothing thing.
Check out this post on blocking powershell with group policy. You can use this tutorial and block the browser exe but this would not work if they need the browser for anything. Web filter or proxy will be the best for controlling internet.
Thanks for your hints
Really that’s great. Yeah we read you from Cameroon ant this post is just GREAT. I just got enrolled in a Company and I am trying to put on a Directory from scratch. This will be very helpful for me
Hello Robert. We currently have an environment of about 65k total users and we are utilizing about 20 of these recommendations currently. I noticed in a comment above that a user was having trouble with ~375+ nested groups per user causing problems with header size and kerberos authentication. I believe we’ve been seeing a few issues related to this lately and we did not realize until now that this could be the cause. What tool(s) would you use to track total nested group membership for a user to prevent this from becoming a more widespread problem?
I have a powershell tool that lists all groups and their members, it includes the objectclass so it can be used to display all nested groups.
I have to give permission to my helpdesk user to be able to change users expire date on other user in OU.
How can I set permisson to this user? what kind of permission ? gonna make me happy if you have some tips for me….
Davoud, put the helpdesk users into an OU then use the delegation wizard to give them this permission.
Here is a video on delegating password reset permissions
I am not sure of understanding your structure.
What is the problem with creating an OU with computers and users inside like the following ? :
Instead of what you do :
Hi Eric, good question.
As long as the computers and users are in separate OUs then I don’t see a problem with that structure.
The first part of this article covering OU design does not sound like it’s written by someone who has ever read the rule book on OU creation. You’re ideas might work for a 50 user organisation but definitely not for a 1000+ user org. Please do not encourage people to create OUs willy nilly for the sake of “organising” things where naming standards and descriptions should suffice. OUs are created when 1) We need OU delegation, 2) A different set of GPOs need to be applied to other OUs or the root level and 3) For different types of objects (users and computers should be separated as you rightly say). OUs are not there to please your aesthetic desires or to help lazy people quickly identify things. That’s what a search is for. And that’s what descriptions and names are for. Because of hard and fast rules like this, AD environments are a mess with no structure at all and a very difficult to untangle configuration.
Are you talking about this rule book? Then yes this is how I design my OU structure.
Designing OU Structures that Work
My recommendation hits on all 3 of the design principles and works on small to large AD environments.
1. Does this OU need to be created so a unique Group Policy Object (GPO) can be applied to it?
2. Does a particular group of administrators need to have permissions to the objects in this OU?
3. Will this new OU make it easier to administer the objects within it?
When adding a new computer to the domain, how do you direct it to the correct OU?
You would have to use PowerShell, there is an example on this page.
Hi Robert! Same question, but a little more dynamic. My work has multiple standalone environments (for the sake of simplicity, lets just say there are no domain trusts). We have a script that can deploy servers in vSphere and join servers to a selected domain through VMWare Guest OS Customization. Because the OU structure is different in the various domains, it is not feasible to specify the OU when the server is created and joined to the domain through the customization script. Otherwise we would have hundreds of customization scripts and it would just be insane to manage and use.
On the domain controllers however, I’ve been searching for a way to dynamically move servers to their proper OU based on the servers name: ie, (server vmtestsql01, needs to go to the servers/sql/test OU), (server vmprdsql01, needs to go to the servers/sql/prod OU).
I’m thinking there’s a way to parse AD objects that land in the servers OU when they are created, and move them according to the name prefix, perhaps a script that runs in task scheduler or other method. I’m just not sure what such a script would look like. Any suggestions?
Thanks for sharing your knowledge! It really helps me understand the complexity of managing AD more.
Excellent, Very good, I want to know what about Backup if Windows server crashed or if anything happened
Pls. guide on this, how can I backup and others..
Really worth reading , Thanks
Thanks for the feedback!
Such a wonderful and huge article! Thanks a lot for you suggestions!
Soon I will have to implement my first AD/DC environment from scratch…
Matteo, thanks for the feedback.
Thanks for posting this blog and its really very helpful information.
Do you have any suggestions for documenting security groups? For example, we have 100+ security groups and from time-to-time I might get a manager to ask “why is so-and-so in that group?” Of course, that change might have happened two years ago and I have no way of remembering who requested that access and why. I’m contemplating a couple of options such as having a document for each security group and making sure I update it each time a change is made to a group. Do you know of any better options?
For documenting adding/removing users to groups I use a ticketing system. Include who requested access, why, and any approval. The last company I worked for we had an approvers list for certain requests (adding to groups was one of them). For example, Alice in accounting puts in a request to access the HR finance folder. This would require approval. We would document all of this in a ticket. Then when someone asked why does Alice have access to the HR finance folder we have documentation for it.
If you have poorly named groups (generic names) then security will get out of control. I have found it best to be very descriptive with the name of the group. For example, group name = “N_Drive_IT_Training_Full”. Just by looking at the name, your staff can probably guess what it is used for. This will help avoid the group from being a catch-all and the wrong people added. Also, use the description field in AD to provide even more details on the group.
Good one! Great posting.
could you provide a solution to find 3rd party systems (or similiar) in the network which are using hard configured DNs? Related to the point 13. of your posting.
I’ll be very graceful if someone has a good idea.
Reason is that we would like to restructure our active directory OU structure. We would prevent of degrading a 3rd party system which is using hard configured DNs.
hmm… I don’t know of any tool for this. You might be able to use PowerShell if you know exactly where to look. You might be able to use Wireshark on the domain controller to see which systems are making the requests.
first of all. Great article. Was a joy to read it. I have a question regarding your point 12. “Automate Common Active Directory Tasks”
I am responsible for a big company with lots of account changes over the year (people coming and leaving) therefore I am very interested how you managed to automate these steps at once (creating the account, adding to groups, creating an office 365 mailbox and creating a personal shared folder) as we are facing exact same challenge. Maybe you have a hint for me to realize this. Thank you.
Most of these can be automated with PowerShell. If you are not into PowerShell then check out my AD Pro Toolkit its a collection of GUI tools that are very easy to use.
Thanks for this list, as a non-admin who needs to understand AD a bit better for one of my projects, it has made it clear that AD is not just a list. Loved your comment that “Active Directory is the heart of the network, if it stops beating then everything else dies.”
My question is this: we’ve had a massive organisational restructure, and many people are now reassigned to different departments/teams/divisions, as well as managers. I’m trying to explain to our network manager that we simply cannot sit and wait around for every affected person to raise a helpdesk ticket, as this would clog up our helpdesk… Is there a way to bulk edit/amend the AD? How can I get them to understand that we need to shake the entire AD out once and for all – and that there are ways to go about it that reduces risk and improves quality?
Hello, this is a very common task that many organizations must deal with. You can mass edit accounts with PowerShell or use a GUI tool. I created a tool just for this, it’s called the Bulk User Updater. You can watch a video demo of it here https://activedirectorypro.com/bulk-user-update-tool/
thanks alot of information amazing