Single Sign On van 3rd party applicatie geeft event id 675

[enveekaa]

Wij hebben sinds kort AdventNet ServiceDesk Plus geïnstalleerd.

Hiervoor gebruiken we een virtuele machine die Windows Server 2003 draait.
Deze server is lid van het domein, en zijn uitvoerig getest met dcdiag en netdiag


De ServiceDesk applicatie heeft een single sign on optie, die er voor zorgt dat gebruikers die willen inloggen op de ServiceDesk niet hoeven in te loggen, maar direct worden geauthenticeerd via AD.
Het lijkt prima te werken, maar, elke login resulteert in 2 failure audits op de domein controller.
Er hebben meerdere domein controllers op deze site, en het maakt niet uit elke er wordt gebruikt om tegen aan te "babbelen", de failure audits blijven.

De exacte foutmelding op de dc is:
Pre-authentication failed:
User Name: jan_jansen
User ID: CONTOSO\jan_jansen
Service Name: krbtgt/CONTOSO
Pre-Authentication Type: 0x2
Failure Code: 0x18
Client Address: 10.20.1.1

Uiteraard heb ik me helemaal groen en geel gezocht op deze event.
EventID.net geeft een hoop scenario’s maar geen van alle biedt uitkomst.
Het gaat om een Windows 2000 native domein, 2dc’s op 1 site.
Iemand die ervaring heeft met dit pakket en Windows 2003? Of die wat meer kan vertellen over hoe dit te debuggen, graag!
Grappig detail is dat ik het in een virtual machine niet kan reproduceren.
Daar heb ik een Windows Server 2003 install met diezelfde software, en daar werkt het wel. Natuurlijk zijn er wel minimale verschillen en deze 2 configs, maar die zouden volgens mij geen impact moeten hebben op iets als Kerberos authenticatie – maar ik kan er naast zitten.

[ Voor 8% gewijzigd door enveekaa op 01-11-2007 15:35 ]

[sh4d0wman]

Hier misschien nog wat zaken die je verder kunnen helpen:

http://www.ultimatewindowssecurity.com/kerberrors.html

http://www.windowsecurity...uthentication-Events.html

Code 18 lijkt te duiden op: Bad password. Account disabled, expired, or locked out.
Heb je dit al gechecked?

Test je trouwens met Win2k3 en moet het met Windows 2000 draaien? Dat werd me niet helemaal duidelijk in je artikel.

[enveekaa]

We testen met 2003 en het moet volgens de leverancier (tevens ontwikkelaars) draaien op Windows 2003.

Ik heb de codes al uitgebreid door google gehaald en die links heb ik ook gelezen. Hele zinvolle informatie, ik weet ook wat er gebeurt maar kan me vinger niet op de zere plek leggen.
Het gevolg is bekend, maar de oorzaak niet, het waarom zegmaar. Als gebruiker kom je wel in de applicatie, dus sso werkt (gedeeltelijk). Maar ondertussen komen er naast een success audit ook 2 failure audits naar voren. Wat weer resulteert in een locked-out account na 2 keer inloggen (4 failures).

Mijn gevoel zegt dat de module die zij gebruiken in hun software kuren vertoond.
Daarentegen heb ik een image waar het wel in werkt dat maakt het zo krom.

Door de leverancier wordt nu gezegd dat het een bug in Windows 2003 is, maar vervolgens geen enkele bron die dat bevestigen kan.
Al met al een redelijk irritante situatie

[ Voor 14% gewijzigd door enveekaa op 02-11-2007 09:23 ]

[enveekaa]

Shopje

Grappige is dat ik de applicatie ook in een testomgeving heb draaien, daar werkt het dus wel.
In de test omgeving wordt er gebruik gemaakt van NTML en niet van Kerberos. Iemand een idee waarom dit zo is? het is in ieder geval geen setting in de applicatie zelf.
De omgevingen zijn zovermogelijk gelijk. Zelfde functional leven e.d., toch "kiest" de applicatie ervoor om in de produktie omgeving Kerberos te gebruiken tegenover NTLM in de test omgeving.

De applicatie draait op een apache/tomcat engine, als die ik zou kunnen forcen NTML te gebruiken zou ik volgens mij ook klaar zijn. Echter kan ik nergens iets van configs vinden...

[sh4d0wman]

Quick reply na lezen van je bericht, komt er misschien iets mee via een Windows (Domain) policy? Daar zitten wel settings in voor ntlm / kerberos.

Als je met google zoekt op "domain policy ntlm kerberos" krijg je wel wat MS documenten te zien, misschien helpt het je iets verder

[sanfranjake]

Misschien had je het al gedaan, maar misschien kan je met setspn of adsiedit eens kijken of er verschillen zijn in de SPN's die op beide omgevingen zijn ingesteld voor alle serviceaccounts/machineaccounts die hierin meedoen. Een SPN (Service Principle Name) niet geregistreerd kan (erg speculatief) deze melding ook veroorzaken? Het kan in ieder geval een hoop rotzooi met kerberos opleveren dus misschien een optie even te kijken, misschien is het pakket in productie geregistreerd door iemand zonder domain adminrechten, welke niet expliciet her recht tot spn's aanpassen was gedelegeerd voor die server?

[ Voor 17% gewijzigd door sanfranjake op 06-11-2007 17:19 ]

[enveekaa]

shadownman: er is inderdaad een hoop te vinden mbt kerberos en NTLM in GPOs. Ik kan echter nergens vinden of en hoe je een bepaalde server kan forcen om NTLM te gebruiken ipv Kerberos.
Overal staat beschreven dat Kerberos default is.. en NTLM enkel wordt gebruikt als Kerberos niet werkt.

sanfranjake: ik heb inderdaad al redelijk zitten klooien met SPNs maar heeft nog niet mogen baten.
Het pakket is in productie geinstalleerd met een domain admin account.

Het vervelende is dat ik het niet kan vergelijken met de test omgeving, want die gebruikt geen Kerberos maar NTLM...

[ Voor 67% gewijzigd door enveekaa op 07-11-2007 10:33 ]

[Question Mark]

enveekaa schreef op vrijdag 02 november 2007 @ 09:15:
Door de leverancier wordt nu gezegd dat het een bug in Windows 2003 is, maar vervolgens geen enkele bron die dat bevestigen kan.

Vraag de leverancier naar het KB-artikel wat dit bevestigd. Als ze dit niet aan kunnen leveren (en die kans lijkt me aardg groot) is het hun probleem en zou ik de leverancier uitnodigen om het op te lossen.

Gezien security-issues zou ik zeker niet terug gaan vallen op NTLM (versie 1/2 ?) om het maar werkend te krijgen. Er zijn meer dan voldoende sniffertools op het web die de NTLM-hash die via het netwerk verstuurd wordt af kunnen vangen en kunnen brute-forcen.

[enveekaa]

@? Ik wil ook niet terugvallen op NTML.. ik wil uitsluiten dat het met de auth methode te maken heeft. Ze hebben me ook 2 kb artikelen gegeven, die mijn inziens niet inhoudelijk op het probleem ingaan.

Inmiddels een stap verder. Ik heb op de applicatie server een firewall geinstalleerd die port 88udp/tcp outbound blokkeerd zodat Kerberos naar de DC niet meer werkt en er automagisch wordt gekozen voor NTLM. En wat blijkt, ook deze geeft exact dezeflde problemen -> 2 failure audits en een succesfull audit.

Het probleem is dus niet te herleiden naar de authenticatie methode..

Dan zegt mij gevoel, oke, de module die de authenticatie verzorgt is gewoon buggy, maar dan kan ook niet helemaal kloppen, want in de test omgeving werkt het als een zonnetje...

http://support.microsoft.com/kb/900215
Probleem met BadPwdCount, iets wat pas gaat spelen als je authenticatie dus niet werkt. Lijkt me geen oorzaak maar een bijzaak.
http://support.microsoft.com/kb/817701
Hoop blabla komt erop neer dat er 1 probleem is rondom Server 2003 SP2 en dat is een hotfix die ook weer niets te maken heeft met het probleem.

Maw ze proberen de boel af te schuiven naar Microsoft, jammmeerrrr!

[ Voor 34% gewijzigd door enveekaa op 07-11-2007 11:46 ]

[enveekaa]

Opgelost.
Er bleek achteraf toch iets niet goed te zijn met de auth module van de software zelf.
Een update van een aantal bestanden was voldoende. Er is nog geen officiele fix uit maar die zal wel snel komen denk ik zo.

Voor de mensen die er ook meet te maken hebben of krijgen hier het draadje;
http://forums.adventnet.c...pic.php?t=172991&start=60

Thanks voor het meedenken!

[ Voor 19% gewijzigd door enveekaa op 19-11-2007 13:35 ]