Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Authority to join PCs to a domain 2

Status
Not open for further replies.

CrimeScene

IS-IT--Management
Jul 5, 2003
59
0
0
Hello all,

I would like to designate a user account to have the authority to join other computers on a LAN to a domain server. Currently, I am keying in the administrator acct/pwd in order to accomplish this.

For example, I have a WinXP computer that I want to log into our domain server from now on. I go to the System Properties window (right-click My Computer, Properties) and select the Computer Name tab. I then click Network ID and follow the wizard. When it prompts me for an account that is authorized to allow this computer to join the domain, I use the domain admin account.

I have a tech assistant that I wish to assume this role, but don't want that person to have the domain admin account's password. Therefore, I would need to designate his account with the privilege of allowing other computers to join the domain server.

Anyone know what options need to be enabled on his account to allow this?

Thanks in advance!
 
Open your Local Security Policy and under User Rights Assignment open up the option Add Workstations to Domain... then just simply add your assistance's name to the list, allow time for replication, and your boy can add pc's to the domain without you worrying about him having to screw something up in the domain..

snoots

"tis better to remain silent and be thought of as a fool..
then open your mouth and remove all doubt" Mark Twain

"I should of been a doctor.." Me
 
Snoot,

Thanks for the advice. However, I apologize for lacking the know-how, but would you kindly provide the exact steps for bringing up the Local Security Policy area (I can't seem to locate that).

Thank you very much.
 
You bet:
(this is on your main server that they authenticate to)
Go to Start, Settings, Control Panel, and open the Administrative Tools.

You should see Local Security Policy inside that folder. If not, go to Start, Search, Files and Folders and search your C: drive for Local Security Policy.

Once inside of it, expand the Local Policies folder and open the User Rights Assignment.

On the right pane, open the Add Workstation to Domain key. Then, just add your little friend to it!

Also, if you can't Local Security Policy on that machine, search other machine's for it and just copy it to that machine.. it's universal so it'll work on any nt box.

snoots
 
Snoot,

I was able to locate the Security Policy area. Strangely, it's nowhere to be found under Administrative Tools or likewise. I added a shortcut to "secpol.msc" and that worked well. Actual shortcut points to:
%windir%\system32\secpol.msc

Now that I am there, "add workstations to domain" has "Authenticated Users" set. While this may be true, I can guarantee you it's not doing what I require. Please allow me to clarify.

In the scenario I originally described, the tech would be sitting at an out-of-the-box computer attempting to join it to our domain server. He is first prompted for a User account + password + domain. Next, he is informed that the computer cannot be found in the domain and is given to option to add it. At this time, he is prompted for an account/pwd that has such privileges. Normally, I would supply the domain admin/pwd which works perfectly. However, I want to specify his account/pwd and have the join-domain-wizard accept it and continue to the next step .. which is to (optionally) add the user account to the client pc (which we would also do).

Again, all this works perfectly when I supply the admin account.

Thanks and looking forward to your continued feedback.
 
When you have a chance, please take a look at my other question concerning IIS upgrade. Thanks!

thread931-772153
 
I'm not sure if I understand your correctly..

So he is or he isn't able to add the PC's to the domain? If you add his user account to the "Add Workstation to Domain" key, he should be able to do it with his typical username/password that he uses to sign into the domain.

snoots
 
Sorry for any confusion.

[snip] "At this time, he is prompted for an account/pwd that has such privileges. Normally, I would supply the domain admin/pwd which works perfectly." [/snip]

The tech would enter his account/pwd, but the wizard running on the client would not accept it ... it's then that we had to provide the domain admin/pwd which worked perfectly.

I read that, by default, an authenticated user can add up to 10 computers to a domain. However, by following your suggestion, they are no longer limited in this capacity.

** NOTE ** I am not able to amend the setting for "Add Workstation to Domain", as the ADD USER OR GROUP and REMOVE buttons are disabled (gray).

If you're 100% certain that your expert advise is correct, then please allow me to re-attempt entering his account when prompted for an authorized person. I will post a follow-up here at that time.
 
Ok. If that area is grayed out, then that means that that domain controller is inheriting it's permissions from a Group Policy, or your not logged on as a domian admin..

You can change this by simply going into AD Users and Computers and blocking inheratance to that DC, or creating a new copy of a current group policy and applying it to that domain controller only... There's lots of options here.. I'm positive on my expert advice, but I'll tell you this: If you go in and block inhertance you may mess up other things, that's why you should 'copy'.. Just so you know, I have probably a dozen different group policy's that are named accordingly and are applied to different users and devices throughout my domain..

gee, i feel like i could teach a class or something.. 8-P
 
Well, I am certainly logged in as the domain administrator.

Where may I see if there is an inherited group policy?

 
Open Active Directory Users and Computers and expand the item that says YOURDOMAIN.COM beside it.. you'll see an OU called Domain Controllers.. Right click on it and hit properties..

Once the box comes up, hit the Group Policy tab at the top.. you'll see the inheritance box at the bottom right..

Even if it's not checked, the policy you must edit is inside the "Default Domain Controller Policy" in the white box.

Hightlight it and hit Edit. It'll bring up a box that looks just like the "Local Security Policy" snap-in... then, under Computer Configuration, just browse to where I said before and add his name..

this is crakin me up now!
snoots
 
FunkMasterWeb stated that he was trying to join the PC to a domain, so why would he use Local Security Policy? Shouldn't he check the settings in Domain Controller Security Policy or Domain Security Policy?
 
Snoot, I did as you requested and the DC/OU was set to "Default Domain Controller Policy". Therefore, does that mean the DC is NOT inheriting its permissions from a group policy? I am confused why the ADD USER OR GROUP and REMOVE buttons were disabled.

Anyway, before I make the suggested amendment, what do you make of "crobin1" comment?
 
He read your comment about the Local Security Policy parts being 'grayed out' and that your should check the domain controller policy.. exactly what i said.

Ok, just hit the EDIT button when you see that Default Domain controller policy, and the Group Policy will pop up. From there, it'll look just like the Local Security Policy so browse to your Security Options and add your techs name where it should go..

snoots
 
Snoots, I followed your instructions.

The setting you referred to was under Computer Configuration, Windows Settings, Security Settings, Local Policies, User Rights Assignment.

By the way, the "Block Policy Inheritence" was NOT checked/enabled. Does that mean that another domain controller's policies can override this server's policies? Currently, we have several DCs, but they were not set up properly in that none of them were designated as the "main gateway" controller (where all computers log into and which dictates enterprise-wide security).

 
What happened to you, snoots? Did you quit on me already?!
 
Hey snoots, not entirely. I am a quick study and have been reading a ton of resource websites. Your insight provided excellent direction. I was hoping to continue our discussion.

As I mentioned, the "Block Policy Inheritence" was NOT checked/enabled. Does that mean that another domain controller's policies can override this server's policies? Currently, we have several DCs, but they were not set up properly in that none of them were designated as the "main gateway" controller (where all computers log into and which dictates enterprise-wide security).
 
First of all, although it may seem that you don't have one "main gateway", you do. Here's a tip to, the leading domain controller in your domain is called the FSMO. Flexible Single Master Operation. You can see which of these DC's is the primary by opening your Active Directory Users and Computers and RIGHT clicking on YOUR DOMAIN.com at the top and going to Operations Masters. There you will see your RID, PDC, and Infrastructure server. More than likely those are all the same DC. Although, those are only three of five FSMO roles. The other two are Domain Naming Master and Schema Master. Those roles pretty much state that one single, or multiple, DC's are in control. The Wolve's among sheep.....that's how I always thought of it..

Now, your group policy stuff.. if that Block Inheritance isn't checked, then that means it can inherit settings. Doesn't matter though, just set the permissions on that OU right there.. Doesn't matter about inheritance now either..


snoots
 
Hello again, snoots.

Right you are again. My "RID, PDC, and Infrastructure" are set to the same value of: myserver.myDC.local

I know we want to take our other servers/DCs and put them "under" this main DC/FSMO. I've read articles that suggest creating Domain controllers in this one domain, so the main DC can replicate directory information to them. In the final scheme of things, we want the main DCs AD/GP to delegate who can log on where and what privileges they have when they get there. All our servers are in-house.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top