Link to home
Create AccountLog in
Avatar of aquariumpro
aquariumpro

asked on

Problems converting user accounts from user to administrator.

Let me begin by stating up-front that I am not an IT by choice; I run an aquarium business and am self-taught in Windows and Win Server so do not necessarily understand all the lingo, but am learning by leaps and bounds. Guess Im saying please take it easy on me and you may need to explain some terminology. Thanks for that in advance. :-)

We have one Windows Server 2003 R2 SP2 set up as a domain controller, WINS server, DNS server and Active Directory. We have nine clients running XP SP2 which are all new installations. We have no policies enforced yet for domain or user groups. The defaults are linked but not enforced.

We were using QuickBooks Enterprise 6.0, which required all QB users to be administrators in AD in order to use the software when running it in a domain/client network. You also had to be careful defining GPOs so I never enforced them, only link-enabled them. I know, thats a security nightmare and IT WAS, with some idiot users installing all kinds of nasty spyware-infested apps all the time. Drove me nuts!

This problem of having to make QB users Admin. was addressed in the latest QB Enterprise 8.0 version, so now QB users can be users. Unfortunately, that version also required us to upgrade from W2000 to XP on all clients.  All our users need to run QB.

So now after installing XP and getting it all configured, Im running into major problems trying to convert from administrators to users. Heres what Ive tried so far:

Removed administrator from each users membership and the one security group I had them all in. I set each user account to take ownership of roaming profile folders. I logged into each client as a local admin and changed the user type on each XP machine to restricted user (trying to avoid power user so my employees cant install junk like Google toolbars).

I rebooted each client and go the Local policy prohibits logging in interactively warning when trying to login.

Problem is, you cant edit the local policy in XP even when logged in as an Admin (local or domain). There is no mention of the need to change local policy on clients in everything Ive read in the many Win Server 2003 books Ive studied, so not sure if it needs to be changed anyway. Doesnt make sense as XP Pro is NT, right?

I know its a permissions or GP thing. I did try running from the cmd line:
runas /user:administrator mmc.exe, then opened up the GP Editor snap-in but User Rights Assignment is still locked.

Help! :-)
Avatar of arnold
arnold
Flag of United States of America image


What is the error message when a user  ( who formerly was a member of the administrators group) logs in on the XP system?  Does it deal with unable to get roaming profile? etc.
If error deals with roaming profile, the location where the user profiles are stored, might have the wrong permissions.  The directory should have group system full access, administrators full access, domain users=full access.

If there are other errors, please post them.

In a domain environment, a domain policy is enforced as a local policy.
If you do not already have Group Polcy Management Console, you can get it http://www.microsoft.com/downloads/details.aspx?FamilyID=0A6D4C24-8CBD-4B35-9272-DD3CBFC81887.
Avatar of aquariumpro
aquariumpro

ASKER

It's a "Local policy of this computer prohibits logging in interactively" warning. Haven't gotten as far as a roaming policy warning as user can't log on.
So if I set a domain policy in AD, it will supercede the local policy of the client machine. I have the GP console and wizard installed.
Sorry, that last was a question, not a statement. If I define a domain policy, will it override the local policy on client machines?
Yes, I think the domain policy will override.

Not sure how you got to the point of newly installed XP client having this policy turned on.  If the domain policy does not work, you may have to use the Microsoft Management Console (start\run\mmc) to add the snap-in from the XP client to edit the local policy to remove said restriction.

Are you by any chance trying to use a normal user to login into the domain contoller?  I think this is the only exclusionary policy as part of the default domain controler policy.

aquariumpro,

Our typical XP workstation has the "Domain User" group assigned to the local workstation's "User" group.  We also have the "Domain Admins" group assigned to the local workstation's "Administrators" group.  This should cover the typical user on a workstation.  However, the permissions on your Server is another story

HTH
From what I've read, local client GP is enforced before domain policy, but I'll try it.

I've already tried using the snap-in on the client machines. As I stated, I cannot edit the local client GP, even when logged in as an admin or when I run mmc as user:administrator from the cmd line.
I'm logged onto the server as an admin. Though that unlocks the Windows GP, the User GP remains locked, even when trying to edit it as an admin. I've tried this as a domain admin and as a local admin.

BTW, XP pro sp2 installation automatically locks the local group policy on installation by default according to a Microsoft article on the topic and they do not give you instructions on how to unlock it. While this may solve a lot of support calls to them, it is a royal pain.
One more thing, the typical Domain user would then be a member of the "Domain Users" group and not any of the "Administrator" groups.
snowdog, that makes perfect sense. I'll try that tomorrow night on one machine and see where I get. Monday's a late night for some employees so I can't do it tonight. Please leave the thread open. Thanks. I'll take any other suggestions too. :)
Darn. I just checked and domain users are already a member of the local users group and domain admins are already members of the local admin group!!! Geez.

Now I was trying this yesterday. Is it possible this was done by AD overnight? Doubt it as it probably happens when you join the domain, but then what else is wrong? I'll try the global domain policy in the AD next.
SOLUTION
Avatar of snowdog01
snowdog01

Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
I do not understand:
Quote from your original question:
"
Removed administrator from each users membership and the one security group I had them all in. I set each user account to take ownership of roaming profile folders. I logged into each client as a local admin and changed the user type on each XP machine to restricted user (trying to avoid power user so my employees cant install junk like Google toolbars).
"

Normally when a computer is joined into a domain, the domain administrators group, etc. is added to the local administrators group.  the domain users group is added to the local users group.

Since you seem to have removed each user from the administrators group, all those users are domain/local users on the XP client.


You have listed that the domain default policies are linked but not enforced.

run the resultant set of policy, that might shed somelight on the issues you have.
snowdog said:
"Are you getting a message saying you cannot edit the local security policy?"

No, but when you double click on it to edit it, everything is grayed out so it can't be edited.

------------------------------------------------------

arnold said: "You have listed that the domain default policies are linked but not enforced. run the resultant set of policy, that might shed somelight on the issues you have."

Sorry to be ignorant, but how do you "run" the policy? I know how to enforce it. Is that what you mean?
OK, try this.  Go the the Start > Run > CMD "command prompt" and type in GPRESULT.  It will take a little bit to gather the information.  Take a look at this and see if anything pops out at you as being odd or wrong.  In understand, you are a novice, but you have been digging in the policy stuff enough already to have some general ideas.
Thanks folks. I'll try the group policy route tomorrow night and will report back on Wednesday with my results.
Ok folks:

I'm finally getting somewhere but only after a lot of trial and error. From what I can tell, in some cases, local policies (like logon locally) seem to override domain policies. I'm not sure how or why, but that's the only explanation I can come up with.

Even though domain users are specified as being able to log in locally, client machines and users are assigned to the domain users group, and my domain policy allows logon locally for users, admins and domain users, you can only logon locally if the user is assigned administrative or power user rights on the local machine.

When you run gpresult on the local machine (or the group policy modeling wizard on the 2003 server), everything looks perfect, but the reality is that the local policy still is taking precedence. Furthermore, only those users with admin rights can load profiles (roaming or local) or change the look of their desktop. The "restricted" user group on XP machines is so restricted that they can't do what I want them to be able to do and can't even use QuickBooks because they can't seem to write to the server database. Yeesh!

So I found this article: http://support.microsoft.com/kb/910203. I then installed the administrative tool kit as described in the article from my Win Server 2003 disk. Voila! using THAT tool, I can now edit local policies - all of them. And users can logon as restricted users. BUT, the users still can't load policies, local or roaming, nor can they change their desktops. The only thing I don't want them to be able to do is install programs.

Where do I look for those policies in the editor?
Another question. Once I perfect the local policy of a client, is there a way I can simply transfer that policy to the other 8 client machines?
You indicated in your initial question that the domain policies while exist do not apply.

When you ran the RSOP on the clients, where did you see the restrictions coming from?

When you joined the new XP systems to the domain, did you use the network ID wizard or the change under the my computer properties, computer name section?
If all the clients were joined to the domain using the change option, that might explain an incomplete setup following the joining (some permissions were not properly set, some policies were not copied.)  Change one system that is currently not working to a workgroup, then following a reboot, join the system to the domain using the network id wizard and see whether the same issue still exists on this system.
arnold: On running the GP results on the clients (as I stated above) there were no restrictions showing and no potential GP conflicts. After creating users as a local admin, I tried both the wizard ID and the manual change mode in both joining a workgroup and joining the domain. Using both techniques failed until I changed the local policy on the clients to not defined.

I am now not having problems with getting restricted or power users to logon. This was a simple matter of loading the W2003 Admin Toolkit so I could edit the local GP. I simply left it undefined so the domain policy could take over there.

But the problem I am now having is that even assigning local power user rights restricts the users TOO MUCH! They can't load either local or roaming profiles. They can't run QuickBooks because they can't access the database. But change their local rights to administrator, and they can do anything they want including installing software and spyware-loaded downloads which I don't want them to do, hence the original reason for posting here.

So they can now logon, but if I assign them local power user rights, they can't get all their work done or modify their desktop. Something major changed from W2000 to XP in this regard. I NEVER had this problem in W2000. A power user could do anything an admin could do except install programs which changed the system. A user in W2000 could do exactly what I wanted them to do. If our latest QuickBooks software did not require XP on clients, I would just wipe them all and go back to W2000.

This seems to be well-documented online. I see many forums where ITs have simply said the heck with it and left all users with local-assigned administrator rights. This is ridiculous.

So my question remains: What can I do to give users the ability to modify their desktops, add favorites, download cookies, etc which are stored in their roaming profile, but NOT allow them to install programs, etc ????????????

In other words, how do I get W2000 local user functionality out of WXP?
You can assign rights to individuals using a domain policy.  In what mode is your AD?
windows XP has a more specific rights assignment as compared to windows 2000 pro.
What are the permissions on the c:\documents and settings directory?  What are the permissions on the share where the users' profile reside and what are are the individual users the owners?

Everything including desktop alterations and rights assignments are set by some security policy.

If my suspicion is right that the AD is in windows 2003 mode, there is nothing you can do to rain in the additional features that come with this AD's mode and the options available under windows XP.

Since you have a live system, you have little choice but to assign these users into the local admin rights.  You would likely need to setup a user and try and see whether using group policies, and rights assigments get a restricted user to be able to login into any system and perform their work.

The problem is I can not see what you do nor can I determine what the possible issue is without you providing the details.

What errors does a restricted user get when trying to work with quickbooks?  Does it relate to their permission in not being allowed to access some directory, share etc.?
arnold said: "In what mode is your AD?" "If my suspicion is right that the AD is in windows 2003 mode, there is nothing you can do to rain in the additional features that come with this AD's mode and the options available under windows XP."

You're the first person to ever say that. Do you have a link to info on this?

Domain fuunctionality was raised after installing Win Server 2003 and that worked perfectly with Win2000. Why would it not work with a later version of windows if it worked fine with an 8 year-old version?

The domain server is in Windows 2003 mode, which according to Microsoft should be MORE compatible with Windows XP Pro clients. According to Windows 2003 Tech files and help files, the only reason to use mixed mode is if there are windows 2000 servers in the domain. Windows 2003 mode is supposed to add more functionalty, not less.

Again, do you have some more information on this as your statement I quote above is exactly the opposite of everything I've read about Win 2003 Server domain level.
The only thing I've read about using XP clients with a Win 2003 mode domain applies only if software restriction policies have been defined at either the local or domain level. I've checked; they are undefined.
SOLUTION
Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
Thanks arnold. I'll look that up. I have a MS Certified Tech coming tomorrow to look into this problem. He stated that he always gives XP clients local Admin status, then limits their rights using the domain policy. I'm not good enough with GP to get taht job done.

The errors I got when assigned as a Power User locally were:

When trying to open QuickBooks (which accesses a database on the server): "Access Denied" with no error code. The application log on the server did not record an event. The application log on the client gave this event:

"The description for Event ID ( 4 ) in Source ( QuickBooks ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: QuickBooks, Returning NULL QBWinInstance Handle."

When trying to open ACT (which accesses a database on the server): "Access Denied" with no error code. The application log on the server did not record an event. The application log on the client also did not record an event.

Now I did get this event recorded for the first time which may explain my roaming profile problem:

"Windows has detected that Offline Caching is enabled on the Roaming Profile share - to avoid potential profile corruption, Offline Caching must be disabled on shares where roaming user profiles are stored."

That could explain a lot. I'm going to correct that and try again.

The location where the quickbooks DB is stored lacks permissions.  domain users, authenticated user  might be the group you are missing.  The share might also need to be read/wrte by all. while the security settings on the directory will manage the other part of the security enforcement.
ASKER CERTIFIED SOLUTION
Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
With all those suggestion and you are electing your own comment as the answer?
With all those suggestion and you are electing your own comment as the answer?

I'm a first timer here arnold and this was my first thread. I selected what worked for me. Isn't that what I'm supposed to do? I apologize if that was the wrong thing to do.
Oh, I just noticed the point system. I was in a rush to join and didn't really pay attention. I'll do some reading of how the board works.
My comment was just that.  It is not an issue for me if you do select your own answer as the solution to this issue.