This Is Why
Just like everyone else, I think it is very common for the contribution of my role to go underappreciated. I can't count the number of times I've been in a meeting with a business unit or other team within the company and heard some version of, "Do we really need to involve the Active Directory team? I mean, it's just managing a few service accounts and groups. I feel like we can take care of that."
Because of our track record (and those of some of those business units), my team is pretty fortunate to mostly get auto-approval from management to manage directory resources now, even when those questions come up. A recent situation reminded me why.
A little background: we have a business unit that was spun up as part of a DevOps initiative several years ago. In that spirit, they requested elevated access over significant portions of the domain they requested. I fought back against the request, but was overruled by a senior director who shied from conflict of that nature (he's no longer with the company, incidentally). So, under documented protest, I granted this BU the ability to manage most resources in that domain.
In short, it has caused a lot of problems. I could go on about them ignoring our naming schemes and Information Security's requirements for service accounts or some members' inability to grasp the basic concepts of the security model we use in 40+ other domains, but I'll highlight a situation that best encapsulates the difference in each team's overall view of the appropriate way to run an environment.
This BU transferred management of service accounts in their domain to my team somewhat recently, but even then, they still sometimes use their access to standard user containers to create effective service accounts. At one point, they created a handful of these (of course, not following our naming scheme and failing to include any creation or descriptive details) and used them in one of their apps.
After a short time, they realized the accounts were locking out almost constantly. I'll fast forward to when a member of my team discovered this. He started with one of the accounts, searched the domain controller logs, found the machines sending the bad credential sets, and worked with the app owner to get the stored credentials updated. In the process, he found out how the account was being used and updated the Description field on the user with the info to make it easier on the next person. He's planning on doing this with the rest of the accounts as time permits. Basically, exactly what I would hope would happen.
Rewind to when the BU had to deal with the same thing however many months ago. After weighing all the options, they decided the best thing to do was set up a script to run every few minutes to unlock the accounts. No investigation of the source of the lockouts (they don't have access), no (apparent) regard for whether the application had full functionality between runs of the script, no thought of involving the owners of the domain for their opinions/ideas. Just a unilateral Band-Aid.
I wish I could say this BU was unique. I wish it shocked me when my coworker told me about this "solution." But the truth is: this is what happens when anyone tries to solve a problem they don't understand. If someone set me loose inside SCCM, I could do something just as short-sighted. The difference is I usually have an appreciation for both my own ignorance and other peoples' expertise, so I'll run any fix I come up with by the appropriate admins first for input. There have been dozens (if not hundreds) of instances of my team saving people or teams from themselves, but we still get left out of the loop on stuff like this because we dare to ask questions and take the time to deploy best-practice, long-term solutions instead of quick fixes. And that's more difficult than doing the first thing that pops to mind.
Because of our track record (and those of some of those business units), my team is pretty fortunate to mostly get auto-approval from management to manage directory resources now, even when those questions come up. A recent situation reminded me why.
A little background: we have a business unit that was spun up as part of a DevOps initiative several years ago. In that spirit, they requested elevated access over significant portions of the domain they requested. I fought back against the request, but was overruled by a senior director who shied from conflict of that nature (he's no longer with the company, incidentally). So, under documented protest, I granted this BU the ability to manage most resources in that domain.
In short, it has caused a lot of problems. I could go on about them ignoring our naming schemes and Information Security's requirements for service accounts or some members' inability to grasp the basic concepts of the security model we use in 40+ other domains, but I'll highlight a situation that best encapsulates the difference in each team's overall view of the appropriate way to run an environment.
This BU transferred management of service accounts in their domain to my team somewhat recently, but even then, they still sometimes use their access to standard user containers to create effective service accounts. At one point, they created a handful of these (of course, not following our naming scheme and failing to include any creation or descriptive details) and used them in one of their apps.
After a short time, they realized the accounts were locking out almost constantly. I'll fast forward to when a member of my team discovered this. He started with one of the accounts, searched the domain controller logs, found the machines sending the bad credential sets, and worked with the app owner to get the stored credentials updated. In the process, he found out how the account was being used and updated the Description field on the user with the info to make it easier on the next person. He's planning on doing this with the rest of the accounts as time permits. Basically, exactly what I would hope would happen.
Rewind to when the BU had to deal with the same thing however many months ago. After weighing all the options, they decided the best thing to do was set up a script to run every few minutes to unlock the accounts. No investigation of the source of the lockouts (they don't have access), no (apparent) regard for whether the application had full functionality between runs of the script, no thought of involving the owners of the domain for their opinions/ideas. Just a unilateral Band-Aid.
I wish I could say this BU was unique. I wish it shocked me when my coworker told me about this "solution." But the truth is: this is what happens when anyone tries to solve a problem they don't understand. If someone set me loose inside SCCM, I could do something just as short-sighted. The difference is I usually have an appreciation for both my own ignorance and other peoples' expertise, so I'll run any fix I come up with by the appropriate admins first for input. There have been dozens (if not hundreds) of instances of my team saving people or teams from themselves, but we still get left out of the loop on stuff like this because we dare to ask questions and take the time to deploy best-practice, long-term solutions instead of quick fixes. And that's more difficult than doing the first thing that pops to mind.
nah. let's not consulte your team. let's just brute force the logins. If anybody asks why its not working, blame the overbearing security team. its clearly a process workflow issue right? RIGHT?!
ReplyDelete