Security Issue: IIS server + 3 domains + SharePoint

[AllGamer]

Example Scenario:

MS SharePoint (web portal software) is installed in PC1

SharePoint doesn't really use IIS at all, except to host the Intro Page for people to Login.

IIS has its own Windows intergated Security check (point 1)
SharePoint uses its own windows integrated Security check (point 2), apart from the one from IIS.

So when users logs in, basically IIS takes authenticate user, then relays security credential to SharePoint

SharePoint receives and authenticate user, then continues and shows its content if authentication is accepted.

Now all the above is how everything it is SUPPOSED to work in the Perfect world.

but here's the dilema...

If IIS Security is configured to use NT Domain Groups/Users then it all works well

If IIS Security is configured to use LOCAL machine Groups, with users from NT Domain Users, then it works erratically.

now supposely if Kerberos authentication is configured properly, the Local machine Group scenario should work right? or does not apply here?


Here is what i think.

Technically speaking it's "illegal" per say to use Local machine groups to circumvent NT Domain groups, by adding NT Domain users into Local machine groups.

and the software pretty much proves my point.

But there are people arguing that Local machine groups should work in the scenario above, by adding NT Domain users into Local Groups.

Why it is wrong me think

When user connects to IIS of this machine it authenticates to the "entity" listed in the ACL

So when using NT Domain Group / Users scenario:

1.Users comes in via IIS
2.machine check againts itself
3.if user is local, authenticate
4.if user is domain, pass to immediate domain or sub domain DC*
5.if authenticate, access allowed
6.if not authenticated, access denied

*DC: if the user is not in the next DC, it will kill asking up the DC chaing until it finds it in the right level of the domain, else, user does not exist.

So now when using the LOCAL machine Group + added NT Domain Users scenario:

1.Users comes in via IIS
2.machine check againts itself
3.machine finds user listed locally
4.machine tries to authenticate user
5.but user does not actually exist Locally*
6.unable to authenticate, access denied
7.able to authenticate, access granted

*and here is the dilema, depending how well this LOCAL machine is configured, it should have been able to authenticate de NT Domain User in its LOCAL group, by asking the higher level DC controller,

but there is a flaw, it will only Ask the DC controller if the user is in the same level of the domain,

say IIS server was joined to PC1.apple.microsoft.com and DCs are:
apple.microsoft.com
orange.microsoft.com
banana.microsoft.com

it will most of the time authenticate users from Apple domain, but not from orange+banana domains

in a multi domain enviroment, the other NT Domain users, does not get authenticated properly.



Well anyways, what do you guys think, it's a Security Flaw in the Microsoft Domain authentication method, or it's a BUG in the Local Machine authentication method?

Any constructive suggestions and comments?

 

[spyordie007]

Sounds to me like a bug, have you tried contating Microsoft PSS about this (I'm curious what they would have to say about it)?

I cant recall what specifically but there are good reasons to use local machine groups with members on the domain for some things...

 

[AllGamer]

i'm more interested in how IIS is actually handling the authentication process either to its local machine, or to the DC, when people from their own workstations are connecting to the IIS Server, and the "SharePoint" server is on another machine.

(it's not actually SharePoint, but we are using SharePoint as an example, it could be any 3rd party web software.)

example the IIS portal machine one, has 2 local groups
Allowed Group
Denied Group

Users added into the groups are NT Domain Users, from 3 different domains as stated before. and as pointed out earlier some users can connect, some cannot, even when all of them should be able to.

Now if we use instad NT Domain Groups, instead of Local Groups in this IIS server, then everything works fine.

So, why is that?

 

[spyordie007]

You sure this issue isnt isolated to SharePoint? I cant confirm or deny it but it just feels like a SharePoint bug using the cross-domain nested groups (i.e. group expansion isnt doing its job right).

Have you confirmed that the symtoms persist using something like a test asp.net application (to rule out SharePoint)?

 

[Smilin]

I'm not a sharepoint/IIS guy (I'm MS networking team) but I can spot a few problems with what you are saying right away:

You will not authenticate from domain to domain. The IIS server will try and authenticate against a DC in it's own domain and that's it. If you belong to another domain a trust must be established and the DC will handle talking to another DC if needed.

If you have groups from other domains (domain users for example) added to a local group they will get the necessary rights as long as the trust is intact and network communication is not blocked.

Also, not sure if you are bumping into this or not, but NTLM can't be used for double hop authentication like kerberos can.

If you are stuck I would suggesting giving MS PSS a call. If it turns out you have a bug the support call will be free of charge and they'll likely get you a hotfix written.