Merkelig autentisering av brukernavn mot AD

[xibriz]

Som sikkert flere kjenner til, er autentiseringen med brukernavn som inneholder æøå mot AD helt sinnsyk.

 

En kjapp test viser:

 

Brukernavn: åruben

 

Godkjente brukernavn:

åruben

aruben

äruben

 

 

Brukernavn: øruben

 

Godkjente brukernavn:

øruben

oruben

öruben

 

 

Brukernavn: æruben

 

Godkjente brukernavn:

æruben

aeruben

äëruben

äeruben

aëruben

 

 

Brukernavn: aruben

 

Godkjente brukernavn:

aruben

äruben

arüben

 

Er det noen som vet om noen flere bokstaver annet enn f.eks. o som kan erstatte f.eks. ø i brukernavnet å fortsatt autentisere?

Endret 11. oktober 2011 av xibriz

[xcomiii]

Hva er det du egentlig vil frem til? Standard praksis er å unngå helt spesialtegn i både user accounts og folder names, ikke nødvendigvis pga AD, men pga applikasjoner som evt bruker autentiseringen til AD tryner ofte pga spesialtegn. Eks Exchange, Dynamics CRM osv.

[xibriz]

Jeg vil fram til om det er noen mønster i at ett brukernavn som oruben kan skrives som õrübéñ og fortsatt autentisere.

 

Altså.. her har jeg ett brukernavn uten spesialtegn (oruben) men jeg kan skrive det i hytt å gevær..

 

Også kan vi ta det ett skritt videre.. en applikasjon som f.eks. mellomlagrer brukernavn men autentiserer mot AD via LDAP vil få flere brukerkontoer på samme bruker avhengig av om brukeren velger å skrive oruben, õrübéñ osv...

Endret 11. oktober 2011 av xibriz

[ice3d]

SID'en er jo den samme uansett hvilket brukernavn du skriver inn, så du vil nok ikke kunne kjøre flere log'ins med ulike variasjoner av brukernavnet.

 

Men som nevnt er det fy-fy å bruke øæå i brukernavn. Har du forresten testet om dette gjelder passord også? Jeg hadde en kar fra det svenske kontoret vårt på besøk hos oss i Oslo som ikke fikk logget inn fordi han fant ikke igjen bokstaven i passordet på tastaturet! Ble nødt til å skifte passordet hans i AD, hehe

[DCG]

SID'en er jo den samme uansett hvilket brukernavn du skriver inn, så du vil nok ikke kunne kjøre flere log'ins med ulike variasjoner av brukernavnet.

 

Men som nevnt er det fy-fy å bruke øæå i brukernavn. Har du forresten testet om dette gjelder passord også? Jeg hadde en kar fra det svenske kontoret vårt på besøk hos oss i Oslo som ikke fikk logget inn fordi han fant ikke igjen bokstaven i passordet på tastaturet! Ble nødt til å skifte passordet hans i AD, hehe

Passord blir ikke lagret i klartekst i AD, kun som en hash. Så problemet vil ikke oppstå.

[xibriz]

Opprinnelig brukernav: øruben

Opprinnelig passord: røben

 

Test brukernavn: ørübêñ

Test passord: røben <-OK

Test passord: roben <-FEILET

Test passord: röben <-FEILET

Test passord: roben <-FEILET

 

 

Scenario 1:

En applikasjon autentiserer mot AD og bruker brukernavn som nøkkel for å kjenne igjen brukeren. Brukeren skriver brukernavnet og får dermed flere brukerkontoer.

 

Scenario 2:

En applikasjon autentiserer mot AD og bruker SID som nøkkel. Brukerkontoen i AD blir korrupt å må opprettes på nytt. Informasjonen om brukeren i applikasjonen er å anse som tapt.

 

What to do???

[xcomiii]

Nå er det ikke utenkelig at at et brukernavn kan være stavet forskjellig, avhengig av hvilken språkinstilling en har under opprettelsen av brukernavnen (som regel på en DC server). Noen land bytter f.eks ut vanlige latinske bokstaver med sine egne, bl.a de baltiske landene har sine særegenheter.

 

Men vil tro de færreste kjører serverne på eksotiske språk, i Norge brukes det utelukkende engelsk.

 

Nå kan det være AD godtar variasjoner av brukernavnet, men ikke passordet siden passordet er kryptert (og alle spesialtegn har sin egen ASCI kode, ergo feiler passord med spesialtegn hvis ikke du har det rette tastaturet).

 

Men jeg forstår fortsatt ikke problemet, hvorfor praktiserer dere brukernavn/passord med spesialbokstaver som er språkspesifikke?

[xibriz]

Men jeg forstår fortsatt ikke problemet, hvorfor praktiserer dere brukernavn/passord med spesialbokstaver som er språkspesifikke?

 

Se bort fra æøå.

 

La oss si at jeg setter opp en applikasjon som søtter autentisering av brukerkontoer mot AD.

 

Når en bruker "ruben" logger inn i denne applikasjonen første gang opprettes det en brukerkonto for han i denne applikasjonen, men autentiseringen av brukerkontoen vil fortsatt foregå mot AD.

 

Når denne brukeren kommer tilbake å benytter brukernavnet "rüben" vil applikasjonen autentisere mot AD som normalt, men applikasjonen vil se at denne brukeren ikke har en egen brukerkonto å opprette den.

 

Men faktum er at nå har ruben 2 brukerkontoer i applikasjonen, men bare en brukerkonto i AD.

 

Han vil derfor kunne logge inn i applikasjonen med brukerkonto 1 (ruben) eller 2 (rüben) og få tilgang til forskjellig informasjon avhengig av endringer han har gjort i applikasjonen.

 

Ser du ikke dette som ett problem så vet ikke jeg?

Endret 11. oktober 2011 av xibriz

[xcomiii]

Vel ser det nå, når du forklarte litt bedre.

 

Det er sikkert mulig å tvinge AD til å sjekke brukernavn nøyaktig mht spesialbokstaver, men hovedproblemet slik jeg ser det ligger i både den eksterne applikasjonen som oppretter brukeren i AD (kjører applikasjonen noen form for "check username"?) og hos brukeren som logger inn (man bør vite om at brukernavn ikke skal inneholde spesialtegn).

Hvis dette er en webapplikasjon med en form, bør det være enkelt å validere username med javscript/Ajax/script på server før det blir sendt til applikasjonen og deretter AD.

 

Eller dere må sette organisatoriske regler som spesifiserer hva et brukernavn kan inneholde/ikke inneholde.

[xibriz]

Den eksterne applikasjonen oppretter ikke brukeren i AD, men lokalt i applikasjonen for referanse til alt brukeren foretar seg i den ekterne applikasjonen.

 

Jeg er nesten enig i deg om problemet.

 

Jeg mener at problemet er endten AD som godtar flere måter å skrive ett brukernavn på, eller brukeren som varierer mellom måten personen skriver sitt brukernavn på.

 

Brukeren er det vanskelig å gjøre noe med, så det beste hadde vært å sette en eller annen instilling i AD som gjorde at brukernavn må matche eksakt og dermed tvinge brukeren til å gjøre det på denne måten.

Endret 11. oktober 2011 av xibriz