2

The computer where the script is executing is in the one domain, I'll call it internal domain. Users which are tested are in the other (external) domain.

I made a script to check if user exist in both domains. Here is a snippet from the script which doesn't cause the problem.

$domain = ‘domain.com’;
$user = ‘username’;

$objuser = New-Object System.Security.Principal.NTAccount($domain, $user);
$objUser.Translate([System.Security.Principal.SecurityIdentifier]) > $nil;

Before I tried executing the third line like this which caused the problems:

$objuser = New-Object System.Security.Principal.NTAccount('username@domain.com');

The problem I'm having right now is that some users from external domain are not shown properly in Windows.

The good example is file properties security tab. The user is shown as

DOMAIN\username@domain.com instead of just DOMAIN\username

This causes all sorts of weird things, such as users who want to access that folder to lose permissions on it.

Is there a way to get the normal behavior back? Restarting the machine is not an option unfortunately.

Vladimir
  • 153
  • 1
  • 8

2 Answers2

1

You're calling two different constructors Vladimir. The working one does just what you expect: set the domain and user from two separate strings. The second constructor, which takes a single string, expects only a user name, and probably uses the domain of the machine the command is being run on as default msdn documentation is somewhat lacking on this.

The problem is that for all intents and purposes their username is username@domain.com, which is where the problem is.

Getting the normal behavior back? either try changing the user name or (gasp) recreating the account object.

If you mean normal behavior as in executing the third line with a single string input then try

$objuser = New-Object System.Security.Principal.NTAccount('username');
MDMoore313
  • 5,581
  • 6
  • 36
  • 75
  • 1
    Beat me to it. :) From [the contructor docs](http://msdn.microsoft.com/en-us/library/97w5k5e8.aspx): *"The specified domain and account names are not required to correspond to an existing account or group, but translation into other IdentityReference-derived types will not be possible unless the account or group does exist."* – jscott Oct 09 '13 at 11:49
  • @jscott nice, I missed that remark, still haven't finished the coffee yet..... – MDMoore313 Oct 09 '13 at 11:50
  • @MDMoore313 thanks for your answer. I figured out what caused the problem but I couldn't change it back. These users are domain users not under my control and I can't figure out why their representation on affected machine is changed by me executing those commands. What do mean by renaming the username? Also when I leave the machine the problem seems to go away by itself except for one username and I don't know why. – Vladimir Oct 09 '13 at 12:30
0

I've found the solution. From what I've figured out I needed to tell the server to get the SID's again and not use the cashe.

Using this support link from Microsoft solved the problem right away without the restart and the one remaining user with the faulty username fixed it self.

http://support.microsoft.com/kb/946358

It is probably safe to enable it again after the problem is solved.

Vladimir
  • 153
  • 1
  • 8