Istek AAI identiteta
Nedavno sam rješavao neobičan slučaj korisnika koji se spaja na Internet od kuće preko meže kablovskog operatera. Korisnik je sklopio ugovor s Bnetom i podesio kućni router da pri spajanju obavi autentikaciju koristeći elektronički identitet koji je dobio na ustanovi.
Korisnik se požalio da mu je iznenada uskraćena usluga, a da nije ništa mijenjao u konfiguraciji routera. Pri pokušaju spajanja dobije poruku: PPTP server not found on specified address. Zvao je Bnetovu podršku, gdje mu je rečeno da će oni proučiti problem i da će ga netko nazvati. Dani su prolazili, nitko nije zvao. Nazvao je ponovo Bnet, ovog puta je operater bio neljubazan, drsko je odgovorio da je kod njih sve u redu i neka se izvoli obratiti CARNetu. Čak je tvrdio kako on vidi da je router dobio IP adresu, što nije bilo točno, verojatno je vidio adresu dodijeljenu modemu.
Korisniku sam sugerirao da se pokuša ulogirati na web sučelju LDAP servisa na ustanovi, kako bi provjerio da li su mu ispravni korisničko ime i zaporka. Sve je prošlo kako treba, a isto korisničko ime i zaporka ispravno su uneseni u konfiguraciju kućnog routera. Dakle problem je u nečem drugom.
U logovima koje radius zapisuje na Linux serveru ustanove pronađeni su brojni zapisi koji pokazuju da korisnikov router svake sekunde obavlja autentikaciju:
Sat Nov 5 11:33:50 2011 : Auth: Login OK: [korisnik@domena.hr] (from client aaics2 port 0)
Sat Nov 5 11:33:51 2011 : Auth: Login OK: [korisnik@domena.hr] (from client aaics2 port 0)
Sat Nov 5 11:33:52 2011 : Auth: Login OK: [korisnik@domena.hr] (from client aaics2 port 0)
Sat Nov 5 11:33:53 2011 : Auth: Login OK: [korisnik@domena.hr] (from client aaics2 port 0)
Sat Nov 5 11:33:54 2011 : Auth: Login OK: [korisnik@domena.hr] (from client aaics2 port 0)
Dakle autentikacija je uspjela, ali zašto router ne dobije IP adresu iz CARNetova adresnog prostora, nego uzaludno pokušava ponovo?
Zatražio sam pomoć AAI@Edu.Hr tima sa Srca. Njihova sugestija uputila me u pravom smjeru. Pružatelji usluga mogu osim korisničkog imena i zaporke provjeravati i neke druge atribute iz LDAP imenika, na primjer datum isteka elektroničkog identiteta! I zaista, korisnik je i dalje imao otvoren račun, ali je u polje Datum isteka temeljne povezanosti bio upisan datum koji je već prošao! Korisnik nije student, pa nije dobio račun na godinu dana, dok ne upiše slijedeću godinu. LDAP administrator upisao je proizvoljan datum, koji je u vrijeme otvaranja računa izgledao daleko u budućnosti, ali vrijeme nemilosrdno teče pa je daleka budućnost neprimjetno postala prošlost.
U polje Datum isteka temeljne povezanosti moguće je za djelatnike u stalnom radnom odnosu upisati vrijednost NONE, obavezno velikim slovima. LDAP administrator će si na taj način olakšati posao, jer neće morati provjeravati kojim je korisnicima isteklo važenje elektroničkog identiteta.
Na kraju, nazvali smo Bnetovu korisničku podršku i objasnili da uzrok problema može biti istek važenja elektroničkog identiteta, tako da ubuduće mogu CARNetove korisnike uputiti da u svojoj ustanovi provjere taj podatak. Ovog je puta operater bio vrlo ljubazan i zahvalio na korisnoj informaciji. Problem riješen.
- Inačica za ispis
- Logirajte se za dodavanje komentara
- PDF version
Komentari
ja sam imao suprotan slučaj.
ja sam imao suprotan slučaj. korisniku je bio istekao el.identitet, ali pružatelj usluge nije provjeravao datum isteka pa se korisnik uredno spajao na internet od kuće, dok se istovremeno nije mogao prijaviti na neke druge sustave koji također koriste AAI. izgleda da provjera datuma isteka valjanosti nije uobičajena praksa kod svih pružatelja usluga
Autentikacija i autorizacija
Zanimljivo.
AAI podrazumijeva Autentikaciju i Autorizaciju. Moj korisnik je prošao autentikaciju, ali nije prošao autorizaciju, tj. nema pravo korištenja usluge. Tvoj korisnik je prošao provjeru identiteta, a dalje sve ovisi o pojedinom davatelju usluge, hoće li pružati uslugu svima ili samo onima koji zadovoljavaju određene uvjete.
Tako je AAI sustav i zamišljen, zar ne? :)
vrijednost NONE
Postovanje,
koliko se sjecam, pri provjeri uskladjenosti nasih ustanova sa normama aai@edu, u polje Datum isteka temeljne povezanosti ne preporuca se vijednost NONE, nego treba biti upisan neki datum. Tako da nam preostaje jedino provjera isteklih datuma.
doris knego pmf st
Vrijednost NONE
Provjerit ću to kod AAI tima. U međuvremenu, pada mi na pamet još jedan način da si LDAP admin bar malo olakša život.
Neka svim korisnicima da istek računa na isti datum, na primjer 1.10.xxxx. Tada se samo treba sjetiti da svakog prvog desetog u godini treba provjeriti da li nekom korisniku treba produžiti valjanost elektroničkog identiteta. :)
Vrijednost NONE
Evo odgovora AAI tima: Vrijednost NONE se ne preporučuje samo za studente, privremeno zaposlene i suradnike.
Slobodno je upotrebljavajte za stalno zaposlene. Naravno, pretpostavlja se da ćete im pri prestanku radnog odnosa zatvoriti račun.
Također, nema razloga da neki od davatelja usluga radi vrijednost NONE u polju Datum isteka temeljne povezanosti uskrati svoje usluge.
Nadam se da ovo pomaže. :)
Iz moga iskustva
Ja sam nekad iz svog starog LDAP kad se prelazilo na AAI shemu povukao NONE za sve korisnike jedno kako su se dodavali novi korisnici oni su automatski dobivali "datum isteka" 31.10.tekuća godinaE sada vremenom su studenti koji su povučeni iz LDAPA polako odlazili i sve sam ih više imao sa vremenom isteka 31.10.tekuća godina i djelatnici NONE.Ja sam tada isto mislio da NONE više nije dozvoljen ali da je to povučeno iz stare sheme.Onda sam jednom masovno cijelom imeniku pred datum isteka promijenio datum isteka 31.10.slijedeće godine i onda su mi i djelatnici dobili datum isttjecanja i nisam ni znao da im mogu NONE dodati.
NONE
U LDAP imeniku na ustanovi sebi sam dodijelio vrijednost NONE, pod istek temeljne povezanosti. Nakon toga se od kuće mogu normalno spajati. Radi se također o Bnetu, tako da ispada da je vrijednost NONE dozvoljena, ne priječi autorizaciju.
Quod erat demonstrandum.
Provjerite sami da li to vrijedi i za druge operatere.
Pozdrav,
Aco