SIDS show instead of user names

[Guest]

I have a Windows 2000, SP4 member server in a single 2003 AD Domain. The
machine is a file server and IIS public Web server.
I log on to the server with my domain account, which has administrator
rights on the server and when I look at either a group's membership, or the
ACL on a folder, I see the SID rather than the user name.

It doesn't appear as though anyone is being denied access. If I add a user
to a group or ACL, I can browse through the domain list of users, but once
they are added and I click OK, they show as only a SID.

I get the same behavior if I try this from a remote machine, either by using
explorer to look at ACLs or Computer Management to look at group membership.
I tried using the showacls command line utility and as long as it is used
remotely, I DO then see the friendly names in ACLs. Also, when logged onto
the server I can see the name of my own domain account, but it is followed by
the SID.

This problem began to happen suddenly for no apparent reason. I see nothing
in the Event Logs that gives any clue.

Does anyone have any suggestions about fixing this?

Thanks.

 

[Vincent Xu [MSFT]]

Hi ,

This issue can occur because the SIDs in ACL are not resolved into friendly
user name immediately. Therefore, there will no access denied issue. If the
problem occur continually or always, please check if the TCP/IP NetBIOS
Helper service set to disabled on the member server. If so, please enable
it.

If the problem happens intermittently, not very frequently, I think it is
the intermittent network issue. The troubleshooting process may be
time-consuming and troublesome. However, please rest assured that I will
try my best to provide assistance.

Thanks.

Best regards,

Vincent Xu
Microsoft Online Partner Support

======================================================
Get Secure! - www.microsoft.com/security
======================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others
may learn and benefit from this issue.
======================================================
This posting is provided "AS IS" with no warranties,and confers no rights.
======================================================



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

 

[Guest]

Hi Vincent -

Thanks for the response. The NBT Helper service is started and yes, this
problem is persistent. It is not something that is resolved by waiting. If
I open a window for a group membership or ACL, I can leave it open for 10
minutes and it still only shows SIDs.

I don't think it's a network issue and it is not intermittent. The reason I
don't believe it is network related is because of the following that I said
in my post:
"I tried using the showacls command line utility and as long as it is used
remotely, I DO then see the friendly names in ACLs. Also, when logged
onto the server I can see the name of my own domain account, but it is
followed by the SID."

One more thing that may or may not apply: File Server for MacIntosh is
supposed to be running on that server, but the service will not start and
both of these problems may have started around the same time. We don't
really need FSM because the Mac users can connect using SMB instead, but I
thought I should mention it for troubleshooting purposes.

Thanks.

 

[Vincent Xu [MSFT]]

Hi,

Thanks for your reply and clarifying.

Let's perform some troubleshooting steps:

2. Please use the tool sid2name.exe tool (attached) to
determine the name of those unknown accounts. Please run the below
one-by-one and
check the output:

Sid2name S-1-5-21-583907252-688789844-725345543-1344
Sid2name S-1-5-21-583907252-688789844-725345543-24842
Sid2name S-1-5-21-583907252-688789844-725345543-24843
Sid2name S-1-5-21-583907252-688789844-725345543-37443


Could you find the account names from sid2name.exe? If it cannot be found,
the user
accounts are probably deleted and cause this problem. If the username can
be shown
from sid2name, please search the user accounts in AD users and computers to
ensure
it is there.

3. If you can find the user accounts name and it is existed in AD users and
computers, please help to capture netmon trace on the problematic file
server.

A. Install the built-in network monitor tools on the problematic file
server.

Windows 2000: (Add/Remove Program --> Add/Remove Windows Components -->
Management
and Monitoring Tools --> Network Monitor Tools --> no need to reboot
machine)

B. Synchronize the time between file server and DC (otherwise it is
difficult to
check in netmon)

C. Run the netmon tool on the file server.

D. Go to Capture --> Networks to choose the correct network card by MAC
address

E. Go to Capture --> Buffer Settings and set 100MB as buffer size (this
setting is
to avoid the trace overwrite itself)

F. Go to Capture --> Start to start capture the network traffic on both
machines.

G. Reproduce the problem by checking the ACL.

H. Stop the capture in network monitor after the unknown account shown.
(Please
note the system time <hh:mm:ss>, we need it to check the netmon trace)

I. Save the network trace and send to me, please also tell me the IP of the
machine.

my email is: (e-mail address removed)

Thanks.


Best regards,

Vincent Xu
Microsoft Online Partner Support

======================================================
Get Secure! - www.microsoft.com/security
======================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others
may learn and benefit from this issue.
======================================================
This posting is provided "AS IS" with no warranties,and confers no rights.
======================================================



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

 

[Microsoft Public Newsgroups]

This problem seems to be the same as the problem I am having. Sorry no
answers yet, but my posting is "Folder security properties slow to resolve
SID's to user ID names" posted 15th June.

PJ.

 

[Guest]

Thanks for the help. I may not be able to get to this today, but I certainly
will do the NetMon trace. I was thinking of using NetMon, but it will be
very helpful for someone else to look at the output.

As far as the accounts being deleted in AD, keep in mind that this affects
every single account (other than the one I'm logged on with) in every ACL and
group, so I already know that isn't the problem. Even if I add a new account
to a group, that user's name disappears as soon as I click OK.

 

[Guest]

I think my problem and yours are not the same, as in my case the user names
never show. I have the seen the problem you describe (extremely slow to
resolve SID to user name) when logging on with either a local admin account
or an account from an untrusted domain.

 

[Paul Bergson]

If this is a public web server in a domain, I'm guessing you have a firewall
that is blocking the name resolution for the sid that comes from AD.

Which ports are open between the file server and AD? Also I would recommend
against having a public web server available to the general public that is
your AD.

--
Paul Bergson MCT, MCSE, MCSA, Security+, CNE, CNA, CCA
http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Thanks for the response.

This is just one of many Windows servers on our large LAN, no WAN involved.
This is the only server on the LAN that is having this problem. I checked
another W2K server that is sitting in the same closet and it doesn't have
this problem. Port blockage is unlikely to be the problem since it appears
to only affect this box, but there are a couple of caveats that I won't
mention for the sake of brevity. Until I check on those, I won't completely
rule this out.

You said "I would recommend against having a public web server available to
the general public that is your AD".
Did you mean to say "... is in your AD"?

I assume that is what you meant to say unless you misunderstood that a DC is
the Web server. This is important to me, because I am trying to get
management to put the Web server on a different box. This will help me make
that point. I argued that a file server shouldn't be a Web server, but I
never really thought that a Web server shouldn't be a domain member. The
only real problem with that would be for administration. They might even be
using domain accounts for access, I'm not sure. (I'm not actually the
Administrator for the server.)

 

[Paul Bergson]

Typo but I would avoid a web server that is part of an Active Directory
environment. That being said we do this but we have a third party managing
all permissions via AD. A better solution would be a reverse proxy with
ISA. I am working on getting this accomplished. A possible other solution
would be to port over your users to ADAM and authenticate against ADAM.

As far as being in the domain. If the server is hacked it has domain level
security whereas if it is a stand alone then the break in is only to this
box.

These are my thoughts but they were built via experience and course work.

--
Paul Bergson MCT, MCSE, MCSA, Security+, CNE, CNA, CCA
http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

All valid points and thanks for the suggestions. If I do rebuild the server
on a different box, it would be with 2003 R2, so ADAM would be readily
available.

As for port blockages, I confirmed that a Windows XP box in the same subnet
on the same domain doesn't have this SID-instead-of-user problem. The other
server that I checked earlier on the same subnet is actually still in an NT4
resource domain, so it wasn't a real good comparison, since it can't use
Kerberos to authenticate to the DC. (All user accounts are in the AD domain.)

To clarify, the problem server IS on the AD domain (which is the only AD
domain and is where the all user accounts live).

 

[Paul Bergson]

Load up LDP from the resource utilities and see if your server can attach to
the dc.

If you don't have the tools installed load them from your install disk.

d:\i386\adminpak.msi (Server tools for remote management of servers)
d:\support\tools\setup.exe (Server Utilities)

Try and query a user object from this web server and from the workstation
you stated can get to the DC. I have included a link on how to use LDP
below.

http://support.microsoft.com/?kbid=224543

PS: Just because a machine on the same subnet can get to the DC it doesn;t
guarantee that other machines can get to it. The firewall may be blocking
by (Allowing only specific ip addresses through) ip address.

--
Paul Bergson MCT, MCSE, MCSA, Security+, CNE, CNA, CCA
http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Vincent Xu [MSFT]]

Hi,

Thanks for sending me the trace data.

I also found that in SID.cap, it contacts 136.167.2.235 and in Name.cap, it
contacts 136.167.2.247. However, I found in Name.cap, an IP: 136.167.2.233.
What IP is this?

Since the problem seems to be related to 136.167.2.235, I suggest you
shutdown this DC temporarily to see if the problem happens again.

Also, did you see the tool sid2name I attached? I'd like to suggest you run
it when the problem occurs to verify at the same time, if the sid can be
resolved. The syntax like:

Sid2name S-1-5-21-583907252-688789844-725345543-1344

Let me know the detailed output.

Thanks.


Best regards,

Vincent Xu
Microsoft Online Partner Support

======================================================
Get Secure! - www.microsoft.com/security
======================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others
may learn and benefit from this issue.
======================================================
This posting is provided "AS IS" with no warranties,and confers no rights.
======================================================



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

 

[Guest]

Thanks, that was a good suggestion.

I ran a query from the problem server on an OU that contains user accounts.
I was able to see the user names of every account. I also have sent the
output from a couple of NetMon captures to Vincent as he requested.

It seemed to me from the start that this was more a problem with the GUI or
something else within the particular server, but I really have no idea what
that might be.

By the way, I realize that a firewall could be set up to allow or disallow
access from certain IP addresses individually, but the firewalls here are not
configured that granularly. Though I have never had access to the firewalls,
I have never seen a problem here where a firewall was misconfigured in such a
way. Because the settings are so basic, the Network people are probably not
likely to make such a mistake.

 

[Guest]

Vincent -

Thanks for the help. 136.167.2.233 is also a DC (we have 4). 136.167.2.235
has all the domain level operations masters, but it is not a GC. A different
DC has the forest wide operations masters and the other 2 are GCs. I again
want to stress that there is no WAN involved and only one AD domain, so there
is plenty of connectivity with the GCs, etc.

I did not use the Sid2name tool because I got the impression that you wanted
me to use it to confirm whether or not the accounts were deleted. Since I
know the accounts were not deleted (remember, I was able to see them remotely
using showacls), I didn't use Sid2name. See my latest response to Paul
Bergson below. He suggested I run LDP from the server. I did that and was
able to see every user name in a particular OU. If you still think that I
should run Sid2name, let me know.

Regards.

 

[Paul Bergson]

I'm going to bow out, no sense in running two threads

--
Paul Bergson MCT, MCSE, MCSA, Security+, CNE, CNA, CCA
http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Vincent Xu [MSFT]]

Hi,

Honestly, it is a weird issue. The reason I suggest you run sidname is that
I'd like to make sure the sid can be resolved at the same time you see SID
in ACL. Please let me know the results in detail (If there are any error
messages.)

Thanks.

Best regards,

Vincent Xu
Microsoft Online Partner Support

======================================================
Get Secure! - www.microsoft.com/security
======================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others
may learn and benefit from this issue.
======================================================
This posting is provided "AS IS" with no warranties,and confers no rights.
======================================================



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

 

[Paul Bergson]

Yes it is odd since he can use ldp and resolve LDAP calls.

--
Paul Bergson MCT, MCSE, MCSA, Security+, CNE, CNA, CCA
http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

OK, I guess it was worth running sidtoname, if only because it adds to the
weirdness. It gives an error and reports that the trust relationship has
failed between the domain and workstation. That makes no sense at all
because I can log on with a domain account and I can still add users to
groups and ACLs and administer remotely and there are no errors in the Event
Logs.

If I look at the same SIDs from my own workstation using sidtoname, I can
resolve them. If I do the same, but append the name of the problem server, I
get the same error message as above.

Here is some other info:
Speaking of Event Logs, user names show as SIDs until I open an event. Once
the box opens for the event the user name shows, but only in the Description
section.
This problem is not 100% consistent; once in a great while I come across a
user name instead of a SID in a local group, but there are very few and the
name is always followed by the SID. If I add one of those users to a
different group I get the same result; I see the user name (followed by the
SID).

Maybe we can simply try removing and rejoining the machine to the domain or
use Netdom to reset the account (even if it doesn't appear as though it's
needed).

 

[Vincent Xu [MSFT]]

Hi,

I agree with you that we may have a try to reset computer account. Please
let me know the results and I will be glad to provide assistance.


Best regards,

Vincent Xu
Microsoft Online Partner Support

======================================================
Get Secure! - www.microsoft.com/security
======================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others
may learn and benefit from this issue.
======================================================
This posting is provided "AS IS" with no warranties,and confers no rights.
======================================================



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