[C#] Asp.net Impersonation probleem

[PeaceNlove]

Ik werk momenteel aan een C# intranet webapplicatie en hierbij loop ik tegen een raar probleem met impersonation aan.
Er is sprake van twee IIS-servers en een webclient in de vorm van chrome.
Server A heeft Windows Authentication enabled, als ik deze benader vanaf mijn client krijg ik netjes mijn gebruikersnaam + domein van de client te zien in de response
Server B heeft Windows Authentication enabled en Asp.Net Impersonation enabled, als ik deze benader vanaf mijn client krijg ik opnieuw mijn gebruikersnaam + domein van de client te zien in de response.

Nu het probleem
Server B wil ook server A benaderen en daarvoor de authenticatie van de client gebruiken. Ik doe dus een request naar server B vanaf de client en server B gaat op zijn beurt een webrequest doen naar server A. De response hierop is een 401.

De credenitals stuur ik als volgt mee aan het request:

code:

req.Credentials = CredentialCache.DefaultNetworkCredentials;

Bouw ik zelf de credentials op in de code, dan krijg ik wel een goede response van de server

Nu lees ik op MSDN

If you enable impersonation and do not specify a domain account as the identity, you will not be able to connect to another computer on the network unless your IIS application is configured to use Basic authentication.

MSDN: ASP.NET Impersonation

Nu de vraag: wat wordt in de quote met specify bedoeld? Is het de bedoeling dat je de user expliciet aangeeft in de config dan wel code en dus niet de impersonated user?

[ Voor 0% gewijzigd door PeaceNlove op 10-06-2014 13:07 . Reden: stomme fout ]

[roviaro]

Hier kun je denk ik wel de benodigde informatie vinden:
MSDN: How To: Use Impersonation and Delegation in ASP.NET 2.0

[PeaceNlove]

Volgens mij de oorzaak gevonden dankzij jouw link: ik moet Kerberos hebben met 'trusted for delegation' op mijn domainaccount van de applicationpool dan wel computer indien serviceaccount. Momenteel wordt NTLM gebruikt op de server en dus werkt delegation niet

[R4gnax]

De courante manier om dit op te zetten is gebruik te maken van trust channels in Windows Identity Foundation.

Als je nog nooit met het WCF en WIF bijltje gehakt hebt, dan is dat wel een hele, hele dikke pil om te slikken, kan ik je zeggen.

[Alex)]

Zo courant is WCF/WIF nog niet. Met een beetje Kerberos-configuratie kun je je doel prima bereiken, zonder dat je hoeft te hacken met trust channels en andere dingen die je over een half jaar niet meer begrijpt.

Wat je nodig hebt is Kerberos op je webserver, een SPN in je AD en de juiste delegation settings op het application pool-account, dan zou alles moeten werken.

[PeaceNlove]

Goed verhaal, alleen jammer dat er in dit project geen WCF gebruikt wordt ;-) De basis is namelijk ArcGIS for Server met windows authentication.

[Alex)]

Wat meer leesvoer: Set up Kerberos Authentication with Delegation on IIS 7 w/ Windows Server 2008

[ Voor 24% gewijzigd door Alex) op 11-06-2014 09:15 ]

[BasieP]

'windows authentication' is NTLM of Kerberos. Als je er niets speciaals voor heb gedaan (lees: je app-pool draait als default network iets) dan is het NTLM.

Volgens mij kun je met NTLM wel impersonation doen. Maar sowieso is het handig om als je een iets groter bedrijf hebt geen NTLM te gebruiken. (ivm, proxies e.d.)

Makkelijkste manier is om je app pool van applicatie A te laten draaien als domainuser x. En die user gewoon rechten te geven in applicatie B.
Volgens mij zou dan alles out of de box moeten werken.

[Alex)]

BasieP schreef op donderdag 12 juni 2014 @ 20:21:

Makkelijkste manier is om je app pool van applicatie A te laten draaien als domainuser x. En die user gewoon rechten te geven in applicatie B.
Volgens mij zou dan alles out of de box moeten werken.

Dat werkt alleen als alle bezoekers van de website hetzelfde moeten kunnen zien en doen in ArcGIS. Als het afhankelijk moet zijn van de bezoeker op de website ontkom je niet aan Kerberos.

[PeaceNlove]

Een van de doelen is editor tracking, dus username van de medewerker moet door Arcgis server verwerkt worden bij de update in de database, vandaar dus dat impersonation van de ingelogde gebruiker een eis is.

[BasieP]

Ik ben nu met precies dit bezig, maar krijg het niet voor elkaar.

De impersonation lukt

wat ik wil is dus :
Persoon x --(kerberos als Persoon X)-> Server A --(kerberos als persoon X)-> Server B

van de browser naar server A dmv kerberos werkt.
Ik kan op server A impersonation toepassen (een file laten schrijven naar de C schijf en die is van owner 'persoon x')
echter wil ik nu vanaf server A een soaprequest doen naar server B.

dit doe ik zo:

C#:

var request = HttpWebRequest.Create("http://site.domein.local/Status.aspx");
request.UseDefaultCredentials = true;

using (var response = request.GetResponse())
{
...
}

Als ik met wireshark kijk op server A zie ik een request verstuurd naar server B zonder credentials.
Dan krijg ik netjes een 401 terug dat ik mij moet authenticeren (negotiate of ntlm).

De app op server A verstuurd dan dit:
POST /sitevanserverB/shizzle.aspx HTTP/1.1 , NTLMSSP_NEGOTIATE
En krijgt een challenge terug:
401 Unauthorized , NTLMSSP_CHALLENGE (text/html)
Dan komt het rare:
POST /cognos10/cgi-bin/cognosisapi.dll HTTP/1.1 , NTLMSSP_AUTH, User: \

Dus de user is '\'
Ik krijg dan ook weer (na best lang wachten) een nieuwe 401 terug..

Wanneer ik ipv UseDefaultCredentials = true hard mijn 'persoon x' credentials in voer kan ik gewoon data ophalen.
Dit wordt dan dit:

C#:

var request = HttpWebRequest.Create("http://site.domein.local/Status.aspx");
request.Credentials = new NetworkCredential("Ikke", "tja..;)", "domein.local");
...

Wat doe ik fout?

[ Voor 9% gewijzigd door BasieP op 26-06-2014 14:08 ]

[Alex)]

Als je zelf een nieuwe NetworkCredential aanmaakt is er geen sprake meer van impersonation, je initieert simpelweg een verbinding met nieuwe credentials.

Als je van server A naar server B wilt met de credentials van de op server A ingelogde persoon, zul je (of je systeembeheerder) ervoor moeten zorgen dat de juiste SPN's zijn ingesteld (service principal names, dit doe je met het tooltje setspn) en dat, indien nodig, de computer-objecten in je Active Directory goed zijn geconfigureerd in het geval van 'Kerberos constrained delegation' (KCD). Met KCD wordt beperkt welke computers en account credentials naar elkaar mogen doorsturen.

[BasieP]

Alex) schreef op donderdag 26 juni 2014 @ 14:56:
Als je zelf een nieuwe NetworkCredential aanmaakt is er geen sprake meer van impersonation, je initieert simpelweg een verbinding met nieuwe credentials.

Ja zover ben ik inmiddels

Als je van server A naar server B wilt met de credentials van de op server A ingelogde persoon, zul je (of je systeembeheerder) ervoor moeten zorgen dat de juiste SPN's zijn ingesteld (service principal names, dit doe je met het tooltje setspn) en dat, indien nodig, de computer-objecten in je Active Directory goed zijn geconfigureerd in het geval van 'Kerberos constrained delegation' (KCD). Met KCD wordt beperkt welke computers en account credentials naar elkaar mogen doorsturen.

Aha dat verklaart het e.e.a.
en hier heb ik al wat mee gedaan om kerberos uberhaupt aan de praat te krijgen.

De authentication error die ik nu krijg komt dus niet omdat impersonation niet werkt, maar omdat deze wel werkt, maar server B zoiets heeft van "Ik accepteer geen tweedehands kerberos tickets."

Toch?
Je hebt zeker niet toevallig de setspn parameters om server B ook de tickets van server A te laten accepteren?

[Alex)]

BasieP schreef op donderdag 26 juni 2014 @ 15:53:
[...]

De authentication error die ik nu krijg komt dus niet omdat impersonation niet werkt, maar omdat deze wel werkt, maar server B zoiets heeft van "Ik accepteer geen tweedehands kerberos tickets."

Toch?

Bijna, de kans is aanwezig dat de server zegt: "Leuk dat je een Kerberos-ticket voor me hebt, maar volgens mijn domain controller mag ik geen tickets van jou accepteren."

Je hebt zeker niet toevallig de setspn parameters om server B ook de tickets van server A te laten accepteren?

Het is niet alleen setspn wat je moet doen (setspn -A voor iedere server/service account), er moet ook wat geconfigureerd worden in de Active Directory. Wat leesvoer: Kerberos for the Busy Admin, Understanding Kerberos Double Hop

[ Voor 6% gewijzigd door Alex) op 26-06-2014 16:05 ]

[BasieP]

top dankje