[asp.net] ntlm proxies loadbalancers sessies

[BasieP]

In het topic \[ASP.Net] asp.net threadsafe maken heb ik het gehad over problemen met het threadsafe maken van bepaalde code.

Inmiddels ben ik er achter dat mijn code reuze threadsafe was, en dat hier niet het probleem zat.

Het probleem is nu iets anders geworden, maar niet minder complex.


Ik heb een loadbalancer waarvan ik weet dat hij soms midden in een sessie mij van node A naar node B gooit.
Op beide nodes heb ik mijn asp.net applicatie geinstalleerd.

- Ik heb IIS zo geconfigureerd dat ik NTLM gebruik voor authenticatie.
- Mijn sessies zijn in proc (wat betekend dat IIS van node A niet weet wat de IIS van node B aan sessie ID uitgeeft. In theorie kunnen ze dezelfde uitgeven)
- Ik heb een loadbalancer die stiekum een proxy is (HAproxy)

Nu is het probleem dat ik soms (als ik net van node gewisselt ben) informatie zie van andere gebruikers.
Het lijkt er dus op dat IIS denkt dat ik gebruiker1 ben terwijl ik daadwerkelijk gebruiker2 ben.

Ik dacht in de eerste instantie dat IIS dan hetzelfde sessieID gebruikt op beide servers, en op het moment dat je switched je dus toevallig in de sessie van een ander komt.
Ik zit dit trouwens doordat ik in mijn applicatie de volgende code aanroep

C#:

var loginName = HttpContext.Current.User.Identity.Name

Dit zou echter impliceren dat:
- IIS de username (via bovenstaande code op te vragen) cached in je sessie, en dus niet elke keer echt naar AD gaat.
- De session ID's zo verschrikkel niet-generiek zijn dat het heeeeel vaak voorkomt dat beide nodes dezelfde id's hebben.

Even ter referentie: Wij hebben misschien 50 gebruikers die heel af-en-toe wat doen. Dus qua kansberekening zou je zeggen dat de (ik dacht) 24 tekens van het ASP.NET sessie ID vrij uniek moeten zijn en dat die kans HEEEEEEEL klein zou moeten zijn.
In de praktijk komt het echter meerdere keren per dag voor.


Zodoende twijfel ik heel erg of dit wel echt de oorzaak van het probleem is.


Op deze pagina word verwezen naar een microsoft document (Authentication Options and Limitations Using Proxy Server 2.0). Daarin staat het volgende:

"The HTTP 1.1 specification states that all state is hop-by-hop only. End- to-end state can be achieved using a cookie or some other token distinct from HTTP"

"In summary, Basic authentication does not require an implicit end-to-end state, and can therefore be used through a proxy server. Windows NT Challenge/Response authentication requires implicit end-to-end state and will not work through a proxy server."


Zodoende zit ik een beetje te denken dat er meer aan de hand is dan die sessies die toevallig hetzelfde zouden zijn.
Echter ben ik niet bekend genoeg met het HTTP1/1 protocol en NTLM.

Is implementeren van Kerberos genoeg om dit probleem op te lossen? hoe makkelijk is dat in IIS? (vinkje heet 'windows authentication')
en moet ik dan mijn applicatie nog ombouwen?

[leuk_he]

Even ter referentie: Wij hebben misschien 50 gebruikers die heel af-en-toe wat doen.

Zou je de balance op de load balancer niet mogen wijzigen(ik neem door die quote aan dat hij er tussen zit omdat de uptime van het systeem belangrijk is en daarom dubbel uitgevoerd, niet zozeer voor de serverload. :

balanace first -> alles naar 1 server tot die dead is, of teveel connecties krijgt.
source -> vaste server voor vaste client

[ Voor 21% gewijzigd door leuk_he op 29-10-2012 17:15 ]

[BasieP]

leuk_he schreef op maandag 29 oktober 2012 @ 17:01:
[...]
Zou je de balance op de load balancer niet mogen wijzigen(ik neem door die quote aan dat hij er tussen zit omdat de uptime van het systeem belangrijk is en daarom dubbel uitgevoerd, niet zozeer voor de serverload.

We zitten nu in een pilot met weinig gebruikers. We gaan naar de 10.000+ toe als de pilot over is. We willen dan ook vanwege de load naar meerdere servers. (meer dan 2 ook)

De loadbalancer gaat ook gefixed worden in die zin dat hij minder vaak zomaar moet switchen, maar dat neemt niet weg dat ALS hij switched, alles gewoon goed moet gaan.

Dat je sessie dan weg is vind ik niet zo erg, die starten we wel weer opnieuw (ik sla niet zoveel op binnen een sessie). Maar dat je de sessie van anderen ziet vind ik wel erg kwalijk. Dit mag gewoon niet voorkomen.

[Woy]

BasieP schreef op maandag 29 oktober 2012 @ 16:21:
Dit zou echter impliceren dat:
- IIS de username (via bovenstaande code op te vragen) cached in je sessie, en dus niet elke keer echt naar AD gaat.

Zoals ik ook in je andere topic gezegd heb ben ik er vrij zeker van dat dat niet het geval is. Dat zou ook een enorm security leak zijn dan. Tevens werkt windows authentication ook gewoon in sessionless applicaties. Maar je kunt het vrij eenvoudig testen door gewoon je session cookie aan te passen naar de session van een andere gebruiker.

- De session ID's zo verschrikkel niet-generiek zijn dat het heeeeel vaak voorkomt dat beide nodes dezelfde id's hebben.

Ik geloof ook niet echt dat het heel vaak voor zou komen dat je duplicate session id's heb.

Ik denk toch echt dat er toch nog ergens anders wat mis is, misschien toch nog een andere manier van output-caching?

[ Voor 4% gewijzigd door Woy op 29-10-2012 18:04 ]

[R4gnax]

BasieP schreef op maandag 29 oktober 2012 @ 17:22:
Dat je sessie dan weg is vind ik niet zo erg, die starten we wel weer opnieuw (ik sla niet zoveel op binnen een sessie). Maar dat je de sessie van anderen ziet vind ik wel erg kwalijk. Dit mag gewoon niet voorkomen.

Je weet absoluut, 100% zeker dat IIS output caching goed geconfigureerd is? Staat static content caching alleen aan voor bepaalde white-listed extensies zoals .jpg, .gif, etc. ? En staat 'dynamic content caching' voor IIS7 ook uit? (Dynamic content caching gaat absoluut fout zodra session state in het spel is.)

[BasieP]

Ik weet niet waar ik die opties moet zoeken.
Op google gister even gegoogled en toen kwam ik uit op een register setting die ik alleen dmv regedit kon aanpassen. Lijkt me sterk dat dat 'de weg' is.

Ik heb IIS6 en geen 7, en ik ging er vanuit dat output caching iets is dat standaard uit staat...

Ik zie in mijn browser ook geen 304, maar alleen 200's. Dus als 'output caching' iets met http standaarden te maken zou hebben zou ik die verwachten.

quote: http://www.drdobbs.com/iis-kernel-caching/184406373

To enable an ASP.NET page for output caching, you have to decorate it with the @OutputCache directive.

^^ dat heb ik dus niet gedaan. Dan staat het toch niet aan?


ow en een veel belangrijker argument:
Wanneer output caching het probleem is dan zou het toch ook fout moeten gaan op 1 server? Het probleem doet zich nu alleen voor als de loadbalancer je omzet van node A naar node B. Er is dan een (ik gok) 50% kans dat je (als er andere gebruikers zijn op die andere node) je zijn/haar sessie krijgt...

[ Voor 24% gewijzigd door BasieP op 29-10-2012 23:50 ]

[Woy]

Ik heb het andere topic gesloten, want het is niet handig dat er nu twee topics over het zelfde onderwerp door elkaar lopen.

[Woy]

BasieP schreef op maandag 29 oktober 2012 @ 23:48:
Ik zie in mijn browser ook geen 304, maar alleen 200's. Dus als 'output caching' iets met http standaarden te maken zou hebben zou ik die verwachten.

Output caching gebeurt juist nog voordat HTTP in het spel komt, dus je zult dan gewoon 200 code's krijgen, alleen hoeft de webserver dan niet de pagina opnieuw uit te voeren, maar geeft gewoon (gedeeltelijk) de eerder gerenderde pagina terug.

^^ dat heb ik dus niet gedaan. Dan staat het toch niet aan?

Ik neem aan van niet, maar het kan volgens mij ook gewoon via andere configuratie aangezet worden ( Bijvoorbeeld web.config )

ow en een veel belangrijker argument:
Wanneer output caching het probleem is dan zou het toch ook fout moeten gaan op 1 server? Het probleem doet zich nu alleen voor als de loadbalancer je omzet van node A naar node B. Er is dan een (ik gok) 50% kans dat je (als er andere gebruikers zijn op die andere node) je zijn/haar sessie krijgt...

Het lijkt me echt enorm sterk dat de kans dat je een sessie overneemt 50% is. En bovendien is de sessie sowieso je probleem niet, want NTLM authenticatie gaat niet via de sessie.

[BasieP]

Woy schreef op dinsdag 30 oktober 2012 @ 08:30:
Het lijkt me echt enorm sterk dat de kans dat je een sessie overneemt 50% is. En bovendien is de sessie sowieso je probleem niet, want NTLM authenticatie gaat niet via de sessie.

Ik heb niet heel goed gemeten, die 50% is een gok. Als het 10% is vind ik het nog erg veel.

Het komt niet heel vaak voor dat de loadbalancer je over gooit naar een andere node, maar ALS het gebeurt heb je wel vaak de sessie van een ander denkt asp.net dat je een andere gebruiker bent.

Mijn web.config ziet er +/- zo uit:

XML:

<?xml version="1.0"?>
<configuration>
  <configSections>
    <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
      <section name="MyFirstProject.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
    </sectionGroup>
  </configSections>
  <connectionStrings>
    <add name="MyFirstCs" connectionString="*knip*" />
  </connectionStrings>
  <log4net debug="false">
    *knip*
  </log4net>
  <system.web>
    <customErrors mode="Off"/>
    <compilation />
  </system.web>
  <applicationSettings>
    <MyFirstProject.Properties.Settings>
      <setting name="MyFirstSetting" serializeAs="String">
        *knip*
      </setting>
    </MyFirstProject.Properties.Settings>
  </applicationSettings>
</configuration>

Niet heel spannend dus...

[Woy]

Het sessie verhaal kun je natuurlijk heel makkelijk uitsluiten op je ontwikkel omgeving. Start je IIS met debugger.
* Open een browser zie dat je authenticated bent
* pak een andere computer met een ander account, zie dat je een andere user bent
* Pas in je browser je session cookie aan naar die van het andere account

Tada: je hebt de session gehijacked, maar in je debugger kun je gewoon zien of de username nog goed is.

[TheNameless]

Dat je NTLM gebruikt veranderd de boel wel aanzienlijk, ik ging er in je vorige topic vanuit dat je formsauth gebruikte

Heb je dit al gelezen toevallig?
http://serverfault.com/qu.../haproxy-and-windows-auth

[ Voor 39% gewijzigd door TheNameless op 30-10-2012 09:21 ]

[BasieP]

@TheNameless

Using NTLM auth over proxies is dangerous BTW because you never know if proxies will multiplex connections or not, which could result in having multiple users browsing with the same account.

Mja dat klinkt idd niet heel veel belovend.
Ik heb nagevraagd of wij multiplex connections aan hebben staan, maar ik weet hier geen drol vanaf, dus ik zal moeten afwachten wat onze loadbalancer man zegt...

@Woy
Ik heb jouw testje uitgevoerd, en inderdaad werkt de username uit IIS halen gewoon.
Ik heb het zelfs gezien in niet-debug mode, door in twee browsers een sessie te starten, en dan cookie te jatten.

[ Voor 19% gewijzigd door BasieP op 30-10-2012 11:35 ]

[Woy]

BasieP schreef op dinsdag 30 oktober 2012 @ 11:33:
@TheNameless
dus ik zal moeten afwachten wat onze loadbalancer man zegt...

Als die loadbalancer man gewoon even zorgt dat je niet meer van server switched, is je hele probleem opgelost

[BasieP]

Woy schreef op dinsdag 30 oktober 2012 @ 11:56:
[...]

Als die loadbalancer man gewoon even zorgt dat je niet meer van server switched, is je hele probleem opgelost

nee dan heb je het probleem onzichtbaar gemaakt.

Als er dan een node uitvalt en je verhuist 5000 gebruikers naar een andere node, en de helft daarvan krijgt opeens gegevens van anderen te zien krijg ik een boze baas op mijn dak.

[Gomez12]

BasieP schreef op dinsdag 30 oktober 2012 @ 17:51:
[...]

nee dan heb je het probleem onzichtbaar gemaakt.

Als er dan een node uitvalt en je verhuist 5000 gebruikers naar een andere node, en de helft daarvan krijgt opeens gegevens van anderen te zien krijg ik een boze baas op mijn dak.

Als ik het topic zo lees en je antwoorden bekijk en zie wat je zelf al gevonden hebt (generaal advies : niet NTLM via proxy laten gaan) dan heb ik nou niet echt de hoop dat jij de magische oplossing gaat vinden die het 100% werkend maakt.
Maar dat jij enkel maar het probleem gaat wegmoffelen zodat het niet zovaak meer voorkomt en als dan de node uitvalt dan heb je de meest rare problemen omdat het opeens weer naar boven komt en opeens werkt geen enkele oplossing van internet meer.

Wat ik vermoed dat er gebeurt is dat IIS simpelweg zijn uitgegeven NTLM's auths per request bijhoudt, dat je proxy deze continu op dezelfde manier door de mangel gooit (waardoor het lijkt te werken) en dat op het moment dat er van node geswitched je proxy de mangel anders gaat doen waardoor je op de nieuwe server kan belanden in een al bestaande auth.

Als je IIS server simpelweg elk tcp-pakketje van de eerst ingelogde gebruiker tagged met 1 (2e gebruiker met 2 etc) en je proxy stuurt dat gewoon door dan gaat het goed zolang je proxy niet van node switched.
Switched je proxy van node en was je gebruiker 1 op server x dan zegt je proxy opeens dat je gebruiker 1 op server y bent en dat kan dus best iemand anders zijn. Kom je binnen als niet bestaande gebruiker op server y dan zal IIS wel daadwerkelijk een AD-call doen en gaat het weer goed. Maar IIS zal nooit per http-aanvraag een AD-call doen (performance technisch niet handig zegmaar)

Oplossing is simpel :
- Of je knalt er een proxy tussen die 100% NTLM passthrough ondersteunt (wellicht MSProxy oid)
- Of je knalt je NTLM auth eruit

Mogelijke (imho extreem ranzige maar volgens mij moet het werken) tussenoplossing :
- Gebruik sessies in je server-side, sla de NTLM username op in je sessie en met je server-side taal vergelijk je de hele tijd of de sessie nog wel de juiste NTLM username heeft, zoniet dan laat NTLM een nieuwe AD-request doen. Zeg maar niet een oplossing die ik zou gebruiken bij 10.000+ gebruikers maar voor 50+ zou het volgens mij wel volstaan.

[BasieP]

Nou..
De kogel is door de kerk.

We krijgen onze oude loadbalancer terug (LVS)

Probleem zat hem in NTLM over proxies icm connection multiplexing.
NTLM doet bij de eerste request over een tcp verbinding authoriseren, en alle andere requests over die verbinding vind hij dan dezelfde user.
De proxy doet aan connection multiplexing, wat betekend dat over dezelfde tcp verbinding er meerdere requests komen (niet persee van dezelfde user!)

De reden dat de auth methode NTLM is komt waarschijnlijk door onze clients die 'negotiate' niet snappen. Nu vind ik dat een applicatie (inc. de bedrijfsproxies die ervoor gezet worden tbv loadbalancing) moeten zorgen dat dit beveilingsrisico er niet is.
IIS zegt (valide) dat hij zowel kerberos als NTLM snapt. Dus daar moet je afblijven, want dit is waar.

De proxy geeft dit echter door als zijnde de waarheid. Dit is niet netjes, aangezien de proxy er juist voor zorgt dat NTLM niet meer (correct) werkt.
een mogelijke oplossing zoud dus nog geweest zijn om de proxy de header te laten aanpassen zodat het voor de client lijkt of NTLM niet meer ondersteund wordt (correcte situatie dus)