VPN-todennuksen taustajärjestelmän migrointi vanhoja tiivisteitä uudelleen käyttämättä

Käyttäjätunnukset ilmestyvät uuteen hakemistoon, migraatio julistetaan valmiiksi ja kirjautumiset epäonnistuvat silti. Yhdyskäytävä tarvitsee edelleen tuetun todennuspolun ja oikean valtuutustuloksen, eikä kumpikaan seuraa hakemistosta, joka nyt sisältää tilit. Taustajärjestelmän siirto on elinkaaren sisältävä katkaisu, ei kopiointityö. Alla oleva oire on se, joka yleensä paljastaa eron.

Oire: tilit ovat olemassa, istunnot eivät

Uusi hakemisto sisältää jokaisen käyttäjätunnuksen, testisidonta onnistuu ja VPN-asiakas palauttaa silti todennusvirheen. Tämä yhdistelmä tarkoittaa, että identiteetti on olemassa, mutta yhdyskäytävän käyttämä varmennuspolku ei tavoita sitä tai tavoittaa sen menetelmällä, jota se ei voi täyttää. Molemmat ovat konfiguraatiota, ja ne ovat eri ongelmia.

Ensimmäinen on johdotusta: yhdyskäytävä osoittaa taustajärjestelmään, joka ei vastaa, käyttää jaettua salaisuutta, jota toinen osapuoli ei odota, tai pyytää määritettä, jota uusi palvelu ei palauta. Toinen on kryptografinen: menetelmä vaatii alkuperäisen salaisuuden, ja uusi säilö sisältää vain sen tiivisteen. Virheteksti näyttää molemmissa tapauksissa samalta, minkä vuoksi niitä kohdellaan yhtenä ongelmana.

Näiden kahden erottaminen ennen tileihin koskemista säästää viikon. Toinen on reitityksen ja luottamuksen kysymys, toinen päätös tunnistetietojen nollauksesta, ja niiden sekoittaminen tuottaa muutoksia, joita kukaan ei voi kohdistaa.

Kartoita ketju ennen kuin ketään siirretään

Kirjoita jokaisesta asiakasprofiilista kuusi asiaa: ulompi todennusmenetelmä, mahdollinen sisempi menetelmä, palvelimen identiteetti, jota asiakas odottaa, yhdyskäytävän ja taustajärjestelmän välinen rajapinta, määrite, jonka yhdyskäytävä yhdistää ryhmäjäsenyyteen, ja siitä seuraava resurssikäytäntö. Niiden lukeminen järjestyksessä näyttää, millä lenkillä ei ole omistajaa. Jokaisella kohdalla on omistaja, ja katkaisu epäonnistuu siinä, jota kukaan ei tarkistanut.

Tavallinen hakemistokirjautuminen ei käy läpi juuri mitään tuosta ketjusta. Se todistaa, että tili on olemassa ja salasana toimii, eli juuri sen osan, josta ei koskaan ollut epäilystä.

Tiivisteet eivät matkusta menetelmien välillä

Tunnistetietojen yhteensopivuus on tarkistettava kerran ennen kuin mikään ryhmä siirtyy. FreeRADIUS kuvaa jaon selvästi: CHAP-tarkistus, jonka palvelin tekee itse, vaatii todellisen salasanan, ja MS-CHAP hyväksyy sen salasanan tai sopivan NT-materiaalin. Muuhun tarkoitukseen luotu tiiviste ei sovi kumpaankaan tapaukseen, olipa se kuinka vahva tahansa.

Ero on siinä, kuka laskee todisteen. Menetelmä, joka varmistaa sitomalla hakemistoon, antaa hakemiston tarkistaa sen, minkä se voi tarkistaa. Menetelmä, joka varmistaa laskemalla haastevastauksen uudelleen, tarvitsee salaisuuden itse, koska palvelimen on suoritettava sama laskenta.

Kun materiaali puuttuu, rehelliset vaihtoehdot ovat tuettu nollaus, uudelleenrekisteröinti, ulkoinen varmennuspalvelu tai menetelmän vaihto. Palautettavien salasanojen väliaikainen vienti ei ole tuolla listalla. Se luo selkokielisen tunnistetietovaraston projektin kaoottisimpana viikkona, ja se yleensä selviää migraatiosta.

Pilottiryhmä, sitten elinkaaren muutokset

Siirrä pieni ryhmä hyväksyttyjä identiteettejä oikealla asiakkaalla ja testaa neljä asiaa: tuore kirjautuminen, tarkoituksella väärä tunnistetieto, resurssit, joihin istunto saa päästä, ja resurssit, joihin se ei saa päästä. Tarkista myös palvelimen identiteetti, jonka asiakas hyväksyi, koska sertifikaatin nimen poikkeama on näkymätön, kunnes joku lukee asiakkaan lokin.

Harjoittele sitten muutokset, joista käyttöönotto todella riippuu. Vaihda salasana, uusi tai rekisteröi sertifikaatti uudelleen ja poista yhdeltä pilottitililtä pääsy. Vahvista jokaisen jälkeen, mikä varmistaja käsitteli yrityksen, koska ennen katkaisua luotu istunto voi jatkaa toimintaansa eikä todista mitään seuraavasta kirjautumisesta.

Erota profiilin toimitus identiteetin vaihdosta. Jokainen ryhmä tarvitsee aiotun profiilinsa, tunnistetietojensa tai rekisteröintinsä tilan, todennuspalvelun, jota sen tulee käyttää, ja tukiyhteyshenkilön, eikä mikään näistä tietueista saa sisältää salaisuutta.

Jos vanha ja uusi polku ovat rinnakkain, rajaa ne päättymispäivällä. Automaattinen paluu voi päästää tilin sisään vanhalla tunnistetiedolla sen jälkeen, kun uusi omistaja on poistanut pääsyn, ja se on tietoturvan regressio saatavuudeksi naamioituna.

Palautus ei voi palauttaa tunnistetietoa

Katkaisun kääntäminen jättää hakemiston täsmälleen sellaiseksi kuin se nyt on. Nollattu salasana pysyy nollattuna, peruutettu sertifikaatti pysyy peruutettuna ja muutettu tunnistetietojen muoto pysyy muutettuna. Ne ovat hakemiston tapahtumia, eikä yhdyskäytävä ollut koskaan niiden lähde. Palautuminen on määriteltävä tapahtumakohtaisesti, eikä mikään siitä saa riippua salaisuuden rekonstruoinnista yhteensopimattomasta tiivisteestä.

Pidä yllä hallinnollinen polku, joka ei käytä siirrettävää yhteyttä. Kun uusi todennus epäonnistuu, keskeytä ryhmä ja käytä sen dokumentoitua palautumispolkua sen sijaan, että heikentäisit todennuksen kaikilta määräajan pitämiseksi.

Kun ryhmät on katettu, poista vanhat taustajärjestelmän tunnistetiedot, profiilit ja luottamussuhteet omistajiensa kautta. Vahvista, ettei vanha polku enää ota käyttäjiä sisään, ja säilytä salaisuudeton identiteetin ja käytännön yhdistäminen, jota tuki vielä tarvitsee. Migraatio on valmis, kun uusi elinkaari toimii eikä kukaan enää pääse sisään vanhaa polkua pitkin, ei silloin kun tililuettelo näyttää täydelliseltä.