Enquiry on a special scenario.

  • Thread starter Thread starter mr_yip
  • Start date Start date
M

mr_yip

Dear Sir/Madam,

I got an enquiry from my customer regarding security
setup. I am developing a system which accept single sign-
on. It means if the user can logon to the network and
have security level to touch different server. He/She can
use different systems, e.g. CRM, MIS .

The customer claims that there is a way to bypass the user
ID and password in the network in order to use all the
resource and systems in the network.

Someone can disconnect a PC physically from the network.
He/She created a domain and user ID in the PC, which same
as the domain and user ID in the network. Then, he/she
logon the domain and user ID in the PC. He/she can
connect the PC to the network again. Finally, he/she can
access all the resources in the network.

Can anyone comment on it ?

Best Regards,

Yip.
 
Your customer is telling porkies if he is talking about Active Directory. A
similarly named local user account will not be able to access domain
resources.
 
Are you sure about this Simon?? I had a Win2003 member server with the
administrator account password set to the same as the domain
administrator's, and the domain FQDN as my primary DNS suffix and was able
to access domain resources seamlessly...

I'm only talking about network file access mind.

--

Paul Williams
_________________________________________
http://www.msresource.net


Join us in our new forums!
http://forums.msresource.net
_________________________________________
Your customer is telling porkies if he is talking about Active Directory. A
similarly named local user account will not be able to access domain
resources.
 
Maybe if a file share and NTFS permissions were configured for Everyone:
Full Control you wouldn't need to specify a domain account. That was a trick
that worked when accessing resources on an NT domain from a 9x PC that
wasn't on the domain.

If a resource has been secured with an AD ACL then I would think not. Could
you access resources restricted to the domain admin using a local admin
account? Security tokens are created by a combination of the users SID and
the SID of any groups the user belongs to. A local Administrator account and
a Domain Administrator account will have different SID's regardless of what
they are actually called.
 
It was a while ago. As far as I remember it was probably just shares...I'm
wondering if the admin shares worked??

I understand the whole SID\GUID\DACL thing, I was just wondering if the info
was passed differently to that of a workgroup...but I already know the
answer - yes; the domain is also passed, so it would be compName\userName
password1 not domName\userName password1. Or perhaps these are never
passed, and the SID is always used. I've just never really 'got' how the
workgroup works, and assumed that a machine gets the username attribute from
a SID and passes that name to the other machine which compares it to its
list of SIDs, one of which has a matching username and password -bingo!

So accept my apologies, Everyone share and NTFS is what I was thinking of...

If you could clarify the whole workgroup access and what is actually passed
username or SID that *would* be great...

--

Paul Williams
_________________________________________
http://www.msresource.net


Join us in our new forums!
http://forums.msresource.net
_________________________________________
Maybe if a file share and NTFS permissions were configured for Everyone:
Full Control you wouldn't need to specify a domain account. That was a trick
that worked when accessing resources on an NT domain from a 9x PC that
wasn't on the domain.

If a resource has been secured with an AD ACL then I would think not. Could
you access resources restricted to the domain admin using a local admin
account? Security tokens are created by a combination of the users SID and
the SID of any groups the user belongs to. A local Administrator account and
a Domain Administrator account will have different SID's regardless of what
they are actually called.
 
It's always the SID that is used, domain names and user names are never
included in the access token, only the corresponding SID's. (This is how it
is possible to identify an Administrator account even when you rename it:
the human readable name changes but the SID associated with the account
stays the same)

Workgroups will work in much the same way. A user in a workgroup will have a
SID added to his access token that identifies the account as being part of
that workgroup.

eg Say the Administrator in Domain A logs on to AD. The Administrators
access token will include the SID of the domain 'abcd1234' as well as SID's
for all the groups the user is a member of.

Now the Administrator from Workgroup A logs on and his access token is also
built in the same way except the SID of Workgroup A is 'xyz789'. Even if the
account has the same username and password the security token is different
because the SID's are different. No usernames in sight when you look at an
access token.

In pre-SP4 Windows 2000 it was possible to manually edit the sidHistory
attribute to add the domain admin SID from Domain A to a user in Domain B,
thus elevating a standard user account from Domain B to be a Domain Admin in
Domain A. Thankfully fixed now by SID filtering.
 
Thanks Simon, but how does pc1\user1 access resources on pc2\user1? The
SIDs are different for each box, therefore the user accounts will have
different SIDs (I believe only the last 3/4 digits are the unique part of a
user SID? -500 admin, -501 guest, -672 paulw, etc.)?

Sorry about this. I've gone from helping to bugging one of the true
guru's...

I've just never really understood how authentication works in a workgroup
;-(

--

Paul Williams
_________________________________________
http://www.msresource.net


Join us in our new forums!
http://forums.msresource.net
_________________________________________


It's always the SID that is used, domain names and user names are never
included in the access token, only the corresponding SID's. (This is how it
is possible to identify an Administrator account even when you rename it:
the human readable name changes but the SID associated with the account
stays the same)

Workgroups will work in much the same way. A user in a workgroup will have a
SID added to his access token that identifies the account as being part of
that workgroup.

eg Say the Administrator in Domain A logs on to AD. The Administrators
access token will include the SID of the domain 'abcd1234' as well as SID's
for all the groups the user is a member of.

Now the Administrator from Workgroup A logs on and his access token is also
built in the same way except the SID of Workgroup A is 'xyz789'. Even if the
account has the same username and password the security token is different
because the SID's are different. No usernames in sight when you look at an
access token.

In pre-SP4 Windows 2000 it was possible to manually edit the sidHistory
attribute to add the domain admin SID from Domain A to a user in Domain B,
thus elevating a standard user account from Domain B to be a Domain Admin in
Domain A. Thankfully fixed now by SID filtering.
 
I see what you mean, I would speculate that each Workgroup has an identical
SID in the same way that each domain does but that's just a guess. I'll do a
bit more digging on that and see what I can find.
 
Great. Thanks.

--

Paul Williams
_________________________________________
http://www.msresource.net


Join us in our new forums!
http://forums.msresource.net
_________________________________________


I see what you mean, I would speculate that each Workgroup has an identical
SID in the same way that each domain does but that's just a guess. I'll do a
bit more digging on that and see what I can find.
 
Back
Top