0

We don't usually use roaming profiles, but we need to test some code of ours to make sure we work with this. This led us to set up a roaming profile and then try to use the program in question.

On all but one machine we tried this on, all was well. On that machine, the product failed. We traced the failures to two phenomena: it couldn't create any COM object, and it couldn't read Scripting.Dictionary.

Further diagnosis revealed the proximate cause: a restrictive ACL on HKLM protected HKEY_CLASSES_ROOT against Domain Users. It didn't even grant read access.

The guy who ran into this did:

secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose 
net localgroup users accountname /add

and everything got better.

I suspected that there's some domain policy involved that needs to be set for Roaming Profiles to be useful that causes this ACL to be set more permissively by default. Of course, that's because I was assuming that it was somehow normal for this ACL to be set this way by default on adding a machine to the domain.

On the other hand, the admin here swears that we have no policies that could explain this. I'm afraid that we've been hit by a cosmic ray.

bmargulies
  • 2,333
  • 3
  • 17
  • 20

2 Answers2

1

Your original post, and the quesiton you asked Ben Z-B don't make sense to me. Your edit make things a bit more clear, but I'm still a bit fuzzy on what you're seeing (more below).

It sounds like you don't know what Roaming User Profiles actually do.

Each user on an NT-based operating system has their own personal "HKEY_CURRENT_USER" registry hive, stored in the "NTUSER.DAT" file in their user profile (stored in either "C:\Users\username" or "C:\Documents and Settings\username", by default and depending on the Windows version). This registry hive is attached to HKEY_USERS at logon-time, and detatched at logoff time. This behaviour is the same, regardless of the local / romaing status of a user's profile.

This "per-user" behaviour of "HKEY_CURRENT_USER" allows programs to store user-specific configuration information in the registry in a location that is the same for every user (i.e. the registry path doesn't refer to the user's account name), but at the same time allows different users to have different configuration information since each user gets their "own" version of "HKEY_CURRENT_USER".

The "roaming" part of Roaming User Profiles comes from the functionality to upload the user's profile data (including the "NTUSER.DAT" file) to a server after logoff, and to download it and cache it locally prior to logon. This upload / download behaviour doesn't change the basic behaviour of the per-user registry functionality in Windows. It's just an adjunct capability that allows user's personalized settings to "follow" them from computer to computer.

The "HKEY_LOCAL_MACHINE" subtree of the registry remains specific to the machine, irrespective of the user who is logged-on. ACLs protect the settings stored in this area from modification by unprivileged users because this is the location of machine-specific configuration information. These ACLs are there for a reason!

The functonality that Ben Z-B mentions in his answer is a common method that we use to alter registry permissions on (potentially large numbers of) computers when poorly written software requires unprivileged users to have less restrictive permission in "HKEY_LOCAL_MACHINE", etc. Further, the functionality he spoke about has NO ramification for roaming user profiles at all, since roaming user profiles are concerned with the "HKEY_USERS" and "HKEY_CURRENT_USER" registry hives-- neither of which can be modified by the functionality he describes.


Edit:

I certainly don't mean to offend. Having dealt with a significant quantity of software, throughout the years developed w/o any regard for proper use of the registry I'm a bit more defensive, perhaps, than I need to be. I've edited my answer to be a bit less preachy and, hopefully, more succinct.

No modification to the ACL at the root of "HKEY_CLASSES_ROOT" (or to "HKEY_LOCAL_MACHINE", for that matter) occurs upon joining a computer to a domain. Your posting doesn't describe the specific ACE(s) that you're seeing added to the ACL at the root of "HKEY_CLASSES_ROOT", so it's a bit difficult to speak to your specific situation.

Any ACL referring to your domain appearing in the registry almost certainly speaks to third-party modification. Microsoft is very, very good about using well-known SIDs and local groups in ACEs they place in the registry.

It sounds as if you've got a group policy object in your domain that's making changes (using the functionality that B-Z describes or by way of a script) to the registry. Using the "Resultant Set of Policy" (RSoP) management console snap-in would probably be helpful to see if any startup scripts, registry security policy, etc are applying (though you could have "trap door" startup scripts running that only execute on the first boot after joining the domain that would no longer be visible in RSoP after that boot).

You could also verify the change is happening by disjoining the machine from the domain, applying the default security template (as you indicate in your comment to B-Z), , then re-joining the domain, examining the ACL before rebooting after joining the domain, and examining the ACL after rebooting again. That would narrow down when the change is occurring.

The use of roaming user profiles doesn't make any changes to the machine's configuration. The flag related to whether a user's profile should be considered romaing is obtained from Active Directory at logon-time and cached in the per user subkey of "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList".

Evan Anderson
  • 141,881
  • 20
  • 196
  • 331
  • please see my edit, and then see if all your hypothetical criticisms of our software development practices still seem apposite to you. – bmargulies Dec 01 '09 at 14:47
  • @bmarguiles: I've dropped on an edit. – Evan Anderson Dec 01 '09 at 15:43
  • I do know exactly what roaming profiles do. I'll put more into the question, but I fear we're all going to have to write this off as cosmic rays. – bmargulies Dec 01 '09 at 15:59
  • @bmarglies: Ultimately, you need to see if you can reproduce the problem by disjoining the domain, fixing the ACL, rejoining the domain, and seeing if the problem recurs. Assuming it does, your admin needs to start going thru the GPOs that apply to this machine with a fine-toothed comb. It isn't normal for any registry ACLs to be modified by joining a domain. – Evan Anderson Dec 01 '09 at 16:17
0

See http://technet.microsoft.com/en-us/library/cc756952(WS.10).aspx :-)

  • Have you actually used this, specifically, to make Roaming Profiles work, or is this just the generic hammer to hit AD registry access problems with? – bmargulies Dec 01 '09 at 13:31
  • LOL @ generic hammer... half my day is spent hitting things with generic Windows hammers. I've never personally come across the issue as described in your edited post - I was working on the same assumption as Evan Anderson. However, you could indeed use group policies to "fix" this though I guess it doesn't get you any closer to understanding why it happened in the first place. What's different about this one machine I wonder? –  Dec 01 '09 at 14:55
  • @Ben Z-B -- I posted the question in the naive belief that we'd walked into some entirely standard and generic roaming profile nuisance, possibly as a result of not following best practices for setting group policy to go with Roaming Profiles. Why this one machine needed secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose followed by net localgroup users accountname /add to fix this ACL, I wish I had a clue. – bmargulies Dec 01 '09 at 15:00
  • The fact you had to repair the local security policies suggests there was something weird on that machine, though ou report that it was joining it to the domain that caused the issue. I've had similar problems that were ultimately due to the machine account not being in the organisational unit (OU) that I expected and so the wrong policies applied. –  Dec 01 '09 at 15:23