Kerberos SSO ja VPN Macilla: vertaa kahta kirjautumispolkua

Kaksi mekanismia tuottavat Macilla saman miellyttävän tuloksen ja käyttäytyvät alla täysin eri tavoin. Toinen hankkii Kerberos-liput SSO-laajennuksen kautta ja välittää ne osallistuville sovelluksille. Toinen pitää selainistuntoa identiteetintarjoajan luona ja antaa verkkosovellusten hyväksyä se. Ne eroavat siinä, mitä ne tarvitsevat verkossa, kuinka kauan niiden tunnistetiedot kestävät ja mitä tapahtuu sillä hetkellä, kun tunneli katkeaa.

Kaksi mekanismia, yksi kirjautumisnäyttö

Lippupohjainen polku riippuu Kerberos-toimialueesta, avainten jakelukeskuksesta ja kellosta, joka on sen kanssa yhtä mieltä. Selainpolku riippuu tavoitettavissa olevasta identiteetintarjoajasta, evästeestä tai tunnuksesta ja sovelluksesta, joka luottaa siihen myöntäjään. Molemmat voidaan määrittää käynnistymään kirjautumisessa, minkä vuoksi ne sekoitetaan samaan ominaisuuteen. Sovellukset päättävät, kumman niistä ne hyväksyvät, ja Mac voi laillisesti ajaa molempia samanaikaisesti.

Vertaa niitä kysymällä, mitä sovellus tarkistaa, kun käyttäjä avaa sen. Kerberos-toimialueeseen liittynyt tiedostopalvelu haluaa palvelulipun, eikä mikään määrä selainistuntoa tyydytä sitä. Nykyaikaisen identiteetintarjoajan takana oleva verkkosovellus haluaa kyseisen tarjoajan tunnuksen ja jättää Kerberos-lipun kokonaan huomiotta. Kun tiedät, mikä tarkistus tapahtuu, käyttöönottokysymyksistä tulee yleisten sijaan täsmällisiä.

Mitä Kerberos-laajennus tarvitsee verkossa

Applen Kerberos SSO -laajennuksen opas kuvaa natiivin Active Directory -todennuksen ja ennakoivan lipunhankinnan, jotka on yhdistetty paikallisiin tileihin toimialueeseen liittymisen sijaan. Se ei voi keksiä polkua toimialueen ohjaimiin. Mac tarvitsee ratkaisijan, joka vastaa Kerberos-palvelutietueisiin, ja reitin, joka saavuttaa ne hyväksytyn tunnelin kautta. Profiili, joka asentuu puhtaasti, ei todista mitään ennen kuin toimialue voidaan todella löytää asiakkaasta.

Tarkista löytäminen ennen tunnistetietoja: Kerberos-toimialueen SRV-tietueiden on ratkettava, ja niiden palauttamien osoitteiden on oltava tavoitettavissa, kun VPN on ylhäällä. Aika on yhtä tärkeää kuin tavoitettavuus, koska Kerberos hylkää pyynnöt kellosta, joka on ajautunut sen toleranssin ulkopuolelle, ja syntyvä virhe näyttää todennusvirheeltä. Mac, joka ei tavoita aikaluhdettä tunnelin ollessa alhaalla, epäonnistuu uudelleen sinä hetkenä, kun se palaa. Korjaa aikaluhde osana käyttöönottoa, ei incidentin vastatoimena.

klist
sudo sntp -sS time.apple.com

Sovelluskohtainen VPN päättää, voiko laajennus toimia

Täysi tunneli reitittää kaiken ja piilottaa tämän ongelman. Sovelluskohtainen kokoonpano reitittää vain VPN-profiilissa nimetyt sovellukset, ja SSO-laajennus on itse prosessi, joka tarvitsee verkon lippujen hakemiseen. Jos sitä ei ole kartoituksessa, paikallinen kirjautuminen onnistuu, tunneli nousee selaimelle ja lippujen hankinta epäonnistuu silti.

Lue VPN-kokoonpano ja luettele jokainen sovellus, jonka se on tarkoitettu kattamaan, ja lisää sitten SSO-komponentti dokumentoidun kartoitusmekanismin kautta sen sijaan, että arvaisit nipun tunnisteen. Näkyvän asiakkaan kartoittaminen eikä sen takana olevan komponentin kartoittaminen on tämän virheen klassinen versio. Pidä kartoitus samassa hallitussa profiilissa kuin laajennus, jotta toisen muutos ei voi äänettömästi mitätöidä toista. Testaa käyttäjällä, joka ei ole koskaan kirjautunut tuolle Macille, koska välimuistiin jäänyt lippu voi saada rikkinäisen polun näyttämään terveeltä, ja testaa sitten uudelleen salasanan vaihdon jälkeen.

Selaimen identiteettistunto on toinen sopimus

Selainistunnolla ei ole Kerberos-toimialuetta, ei palvelulippua eikä kellotoleranssia Kerberosin mielessä. Sillä on myöntäjä, tunnuksen elinikä ja päivityspolku, ja sen vikamuodot ovat uudelleenohjauksia, jotka eivät koskaan valmistu, ja evästeitä, jotka yksityinen ikkuna hylkää. Sen kohteleminen lippupolun korvaajana on turvallista vain siellä, missä sovellus itse hyväksyy kyseisen myöntäjän. Todennusvastauksen kopioiminen VPN-portaalista riippumattomaan palveluun ei ole integraatio, niin kätevältä oikotie näyttääkin.

Kun molemmat mekanismit on otettu käyttöön, dokumentoi, mitkä sovellukset käyttävät kumpaa, koska tukikeskustelu riippuu siitä. Käyttäjä, joka kertoo olevansa kirjautunut mutta ei voi avata tiedostojakoa, kuvaa kahta järjestelmää, ja vastaus on, että lippupolku ei koskaan käynnistynyt. Käyttäjä, joka voi avata jaon mutta ei intranet-portaalia, kuvaa päinvastaista, ja mekanismin nimeäminen tiketissä säästää yhden kysymyskierroksen.

Käy läpi järjestys, älä osat

Käy koko ketju läpi tavallisella rekisteröidyllä tilillä: paikallinen kirjautuminen, tunneli, lippujen hankinta ja sitten yksi todellinen toiminto palvelua vastaan. Toista se tunnelin uudelleenyhdistämisen jälkeen ja tarkoituksellisen salasanan vaihdon jälkeen, koska jokainen näistä tapauksista harjoittaa eri osaa elinkaarilogiikasta. Jokaisen vaiheen läpäiseminen erikseen ei ole sama kuin toimiva ketju. Ketju on se, mitä käyttäjä kokee, ja se on se, minkä hyväksymistapauksen on katettava.

Kirjaa profiilin omistaja, VPN-todennusmenetelmä, toimialueen löytämispolku ja laajennuksen sovelluskartoitus yhteen paikkaan. Juuri se kirjaus tekee virtauksesta toistettavan sellaiselle, joka ei rakentanut sitä. Tarkista sitten vika, jonka todennäköisimmin kohtaat, vanhentunut lippu tunnelin ollessa alhaalla, ja vahvista, että asiakas palautuu ilman uudelleenkäynnistystä, koska käyttöönotto, joka toimii vain kylmäkäynnistyksestä, ei ole valmis.

Merkitse myös kunkin vaiheen omistaja, koska Kerberos-toimialueesta, jota kukaan ei ylläpidä, tulee vanhentunut. Ketju, jota kukaan ei osaa kuvata, on ketju, jota kukaan ei osaa debugata.