Symptoms Out of nowhere, domain members start throwing errors about their trust relationship with the domain not working. You could also be receiving general logon errors by interactive users and service accounts. The behavior will likely be limited to one AD site, but will occur on seemingly random servers within that site. Resolution Check the drives where the NTDS database exists on all domain controllers in that domain. If any have filled up, expand them or clean them off, then reboot the affected servers. If you cannot log into the servers via console or RDP, try to force a shutdown through the hypervisor or chassis (if applicable). As a last resort, do a manual power-down via button or power cable, then boot up. See the Notes section for more details of this specific incident. Cause Normally, when a Windows machine does a domain authentication/authorization check, quite a few things happen in the background. One of those things is finding a working domain controller

Symptoms This can manifest in many different ways. Here are some of the most common: Support personnel report they can't unlock or reset the password for a user even though the target user's account is in the same OU as many other accounts that are behaving normally. Support personnel report they can't change the membership of a group even though the target group is in the same OU as many other groups that are behaving normally. Support personnel report they can't modify an attribute for a user even though the target user's account is in the same OU as many other accounts that are behaving normally. The primary identifying characteristic of the situation described here is the resetting of the security of whatever object they're trying to modify. IE, you may be able to grant support personnel rights to modify it, and it will work, but the next time they go back to do the same, the permissions are missing again. To confirm the underlying issue is the on

Symptoms Synchronization tasks within Azure AD are not kicking off at all. No errors are present in the application/system logs. In fact, nothing is in the application logs. Resolution Make sure all the appropriate ADSynchScheduler properties are set correctly. Open Microsoft Azure Active Directory Module for Windows PowerShell .   Run the following command: Get-ADSyncScheduler The result should be something like this: AllowedSyncCycleInterval : 00:30:00 CurrentlyEffectiveSyncCycleInterval : 00:30:00 CustomizedSyncCycleInterval : NextSyncCyclePolicyType : Delta NextSyncCycleStartTimeInUTC : 12/15/2017 5:19:45 PM PurgeRunHistoryInterval : 7.00:00:00 SyncCycleEnabled : True MaintenanceEnabled : True StagingModeEnabled : False SchedulerSuspended : False SyncCycleInProgress : False Make sure SyncCycleEnabled is set to True and SchedulerSu

This is part of my ongoing AD Design series. Check here for primer on the intent. As mentioned in my last post, I'm going to assume a certain level of knowledge about Active Directory is held by the readers of this series. One of those assumptions is you can navigate the wizards necessary to promote a couple domain controllers and get a base domain up and running. Again, if that's outside of your abilities, there are many, many guides for that online. For this post, I'm going to assume you're starting with a brand new domain. It may seem elementary, but two of the most important things to consider in AD design are: How your configurations will affect existing systems within the domain.  How your configurations will affect future efforts within the environment. How long you've been managing domains and your knowledge of how your systems integrate with your domain will determine how well you're able to guess at those (and make no mistake, you are

Active Directory (AD) is one of the more flexible products provided by Microsoft. While they have spreadsheets and white papers for how many users should be in each on-prem Exchange database or how you should structure your site collections in SCCM, guidance on AD design is kind of sparse. My assumption is because directory designs are so environment-specific as to be resistant to generic instructions. This flexibility means two things: You can tailor the configuration and security of a domain to precisely and efficiently match the requirements of the environment it's there to support, making maintenance easy and allowing for future expansion.   You can screw things up really, really badly and not even know it. You see, the assumption in AD overall is you know what you're doing. There are very few warnings, no popup to let you know you just granted Bob in Accounting the keys to the kingdom or an easy wizard that lets you review your configurations before deploying them to

In my company, my overall department often takes over environments for business units who have built their own, then found they lack the time/knowledge to manage it effectively. It then falls upon my team to reorganize the Active Directory domain to follow industry/internal security standards and best practices. This article covers one of the most common low-level offenses we encounter: shared service accounts. Like so many questionable decisions, using a shared service account seems like such a good idea on the surface. You only have to create one account in AD, you only have to record and track one set of credentials, app installers only have to remember one set of credentials, permissions for different processes will likely overlap (meaning you only have to grant the access once), etc. However, I have a personal story that will help highlight why you're playing with fire. Let's travel back to early 2008. It was the first week of my current job, and I was trying to learn