Create a Least-Privilege account to perform domain joins

I’ve been working to automate joining linux machines to an Active Directory domain lately and I was surprised to find little documentation on creating an AD account just for the domain joins. I was able to piece things together by looking at umpteen documents and lots of trial and error. I’ve compiled what I found in the hopes that others do not have to struggle so much. This is just what I was able to find out – please let me know if you have a better way!

 

In a Windows Active Directory domain, it’s important to join computers to the domain. When the computer is joined, the computer account is created and lets it do things like send user authentication requests/receive responses, update it’s IP/name in DNS, and otherwise participate in the AD domain. This is a pretty fundamental and vital requirement, so Microsoft has made it easy for users to perform domain joins, but with some limits.

If a user is a enabled, a member of Domain Users, a member of the local Administrators group, and the correct authentication information is used, they are granted the ability to join any given computer to a domain. The key ms-ds-MachineAccountQuota is defined at the domain level with a default value of 10. Due to the quota, any random user can join 10 computers to the domain after which they will no longer be able to do so. Enabled members of Domain Administrators are exempt from both local Administrators membership and the quota and can join unlimited computers so long as the correct authentication information is used.

This works great with Windows machines, but presents a slightly different problem when joining non-Windows machines to a domain. In these cases, there is likely no local Administrators group, so regular users are never able to satisfy all of the requirements to join a machine to the domain. Domain Administrators can, but that violates the principle of least privilege and is not the best option for production environments. We want a non-administrator account who can join as many computers to the domain as is required. I found two steps were required to create this account.

Active Directory Delegation

In the Active Directory Users and Computers MMC snap-in, you can use the Delegate Control wizard to delegate the ability to create computer accounts to a user account. Unfortunately, I have not found scriptable commands that are an equivalent to this wizard, so we need to describe the GUI process.

  • Create an account, ex: domainjoin, in the appropriate hierarchy of your Active Directory. It is recommend that User cannot change password and Password never expires are selected so the account is always available. It will not have ability to log into a server or any elevated privilege.
  • Delegate the ability to manage computer objects to the user with the Active Directory Users and Computers snap in (from JSI Tip 8144 with tweaks).
    • Open the Active Directory Users and Computers snap-in.
    • Right click the container under which you want the computers added (ex: Computers) and choose Delegate Control.
    • Click Next.
    • Click Add and supply your user account(s), e.g domainjoin. Click Next when complete.
    • Select Create custom task to delegate and click Next.
    • Select Only the following objects in the folder and then check Computer objects and Create selected objects in this folder. Click Next.
    • Under Permissions, check Create All Child Objects and Write All Properties. Click Next.
    • Click Finish

Increase the MachineAccountQuota value

The second step is to increase the quota from the default value of 10. This appears to be done domain-wide, so all users will get the new quota. I somehow doubt that will be a problem, but if it is, you will have to do further research on how to proceed. To increase the quota, we just need a single command entered in an Administrative PowerShell terminal.

Set-ADDomain example.com -Replace @{"ms-ds-MachineAccountQuota"="10000"}

I used 10,000 because we have less than 100 nodes ready to join the domain. You can increase the value if your scale is a bit higher. I’m sure there’s a way to reset the quota, too, I just haven’t found it yet.

Joining your node to the domain

You’re now ready to join your node to the domain with your new least-privilege account domainjoin. I have created a puppet module, domain_join, to meet my personal needs. I’d love to hear how you’re tackling this issue, especially if the solution is better than mine!

“No Deploy Friday” is a sign of IT Maturity

Last Friday, I made a pretty sarcastic joke about Friday deploys. Hopefully the image macro let you know it was a joke, though!

You shouldn’t be deploying on Fridays. Let’s qualify that a bit. “Deploy” in this instance means a high-risk change – a new product or equipment, a change in some protocol (moving from EIGRP to OSPF), or even some simple change that you’ve not done before so you don’t really know how risky it is – and “Friday “is your last day of the week. Patches on Friday? Up to you, though I don’t suggest doing so at 4:59PM. Is your shift 4×10, Monday through Thursday? Thursday is your Friday, get your deploys done by Wednesday. Is it a short week because of vacation plans? Maybe don’t deploy this week at all. Whatever the particulars are for you, “No Deploy Friday” is just the phrase for not deploying something brand new before you’re off for a few days.

Having the “No Deploy Friday” rule is a sign of IT maturity, for you and your company, in so many ways:

  • Realizing you cannot do everything. Sometimes you can’t do something when you want to. It’s better to accept that than try and force it.
  • Realizing that things go wrong. When you’re young, it’s easy to believe so fiercely that you know what you’re doing that you cannot accept that you might be wrong. With maturity comes the knowledge that even if you know what you’re doing, it can still turn out poorly.
  • Realizing that your decisions affect those around you. It’s important to recognize that when something does go wrong, you don’t exist in a vacuum. Other people are affected. Your boss and coworkers. Your customers. Your family. Your coworker’s family. You can make the decision that YOU do not mind staying late if something breaks, but you should not make the decision for your coworker’s spouse that they won’t be home for dinner.
  • Realizing that you matter. Work has to happen. But you don’t have to subsume yourself for it to happen. Your time off is yours. Friday movie night should be for watching movies, not fixing bad deploys. And instead of pushing a big deploy before you head on vacation, which pretty much ensures through Murphy’s Law that you won’t actually get to enjoy your vacation (or worse, you will but your company and users will suffer until you’re back on the grid!), talk to management and push the deploy out or find another owner. There’s also the more serious struggle with burnout that we all have. Reminder: You matter! If you need help, reach out to someone! We’ll listen!
  • Realizing that no matter what gets done today, there will always be more tomorrow! When I was younger, I sometimes thought I might “work myself out of a job”. What BS. If I ever actually did get everything done, it would have just given me time to find something else to do. For most of us, we’ll never actually empty out our task list. Since that’s the case, there’s no need to kill yourself trying to do so. This isn’t the same thing as saying, “feel free to slack.” It’s a fine line to know what NEEDS to be done today and what would really be nice to do today but would be more likely to be successful on another day. Knowing when you should postpone work until you have the time to do it right is another sign of maturity.
  • Realizing that “hurry” is the antithesis of “fast”. This one is counter-intuitive. We’re often told to, “move fast and break things.” I hate that saying. It really should be, “move fast and break things in development so you don’t break production.” That’s the real intent behind it. But even that’s not right. “Hurry” indicates your speed; “fast” is describing your velocity.  When you’re hurrying, it becomes easy to skip a step because someone hit you up on IM while you were working, or push through an error message because you want to leave to get to the movie on time. Those things end up costing you more time when you have to drop everything to troubleshoot or rollback. Now you’re hurrying at a high speed but have a negative velocity. You show maturity when you choose a velocity of zero over a negative velocity.
  • Realizing that Friday is great for “non-work” work. We work in a fast paced industry. We spend a lot of time working, but we have a lot of other things we have to do that we don’t always consider “work”. No-one likes doing their expense reports, but they’re great Friday work. We also have to keep up with new technologies and processes, and if you have an 8+ hour day with no deploys, it’s a good candidate for some contiguous learning time. There’s lots of ways to be productive while avoiding deploys, and your manager and finances will also be happy that they don’t have to hound you for your expense reports anymore!

It’s often a difficult struggle for maturity in IT. Just knowing what maturity looks like, doesn’t mean you can just go ahead and do it. If you’re in a culture of Friday deploys, you may have to lead the charge on this. If you’re the rogue IT person breaking the “No Deploy Friday” rules, talk to your coworkers and see what wisdom you can glean. Let maturity be your badge of pride, not your scars and war stories!