Active Directory -todennuksen / AD-kirjautumisen vianmääritys...

"Apua! Käyttäjäni eivät voi kirjautua sisään PaperCut User Web Interface-, Client- tai Mobility Printiin Active Directory Domain -tunnistetiedoillaan, mutta sisäiset käyttäjätilit voivat kirjautua sisään hienosti. Mitä tapahtuu?"

Huomaa: PaperCutista ja Active Directorysta yleisempiä usein kysyttyjä kysymyksiä on Active Directory -tietokannassa.

Tämä voi olla ongelma, jos olet linkittänyt PaperCut-sovelluspalvelimen käyttämään Active Directorya käyttäjähakemistolähteenä (katso käyttäjien ja ryhmien synkronointi Active Directoryn tiedot)…. ja jostain syystä sovelluspalvelin ei enää "puhu" Active Directoryllesi (AD).

Tämä ei vaikuta käyttämiisi sisäisiin käyttäjätileihin, koska todennusta (ja salasanaa) hallitsee kokonaan PaperCut. Samasta syystä AD-viestinnän ongelmat eivät myöskään vaikuttaisi sisäänrakennettuun "järjestelmänvalvojan" tiliin.

Tarkista ilmeiset asiat

Onko numlock tai caps lock päällä? (Meidän on kysyttävä). Vahvista, että ongelma koskee vain verkkotunnuksen kanssa synkronoituja tilejä. Katso, voiko joku todentaa sisäisellä käyttäjätilillä, kuten sisäänrakennetulla järjestelmänvalvojalla (kirjautumalla verkkokäyttöliittymään tai tulostamalla Mobilityn kautta). Jos näin on, ongelma saattaa koskea vain Windows Active Directory -tilejä. Varmista, että testattavan tilin salasana on täysin oikea. Mitä tapahtuu, kun nollaat käyttäjän salasanan Active Directoryssa ja kopioit/liität sen sitten käyttöliittymän kirjautumissivulle?

Lisä vianetsintä

Varmista, että Netlogon-palvelu on käynnissä PaperCut-palvelimella< /h3>

Ainakin yksi asiakas ilmoitti meille, että verkkotunnuksen käyttäjät eivät voineet todentaa sen jälkeen, kun he ovat päivittäneet Windows-tulostuspalvelimensa vuodesta 2012 vuoteen 2016. He pystyivät ratkaisemaan ongelman noudattamalla tämän Microsoftin artikkelin ohjeita. netlogon-palvelu (katso Ratkaisu-osio, joka korostaa kuinka Netlogon-palvelun käynnistystyypiksi muutetaan Automaattinen, ja varmista, että palvelu käynnistetään).

Artikkelissa suositellaan myös palvelimen uudelleenkäynnistystä, vaikka se ei ole ehdottoman välttämätöntä.

Tarkista Windowsin suojauslokit

Tarkista, käsitteleekö Windows todennuspyyntöjä ollenkaan. Avaa paikallinen ryhmäkäytäntöeditori: paina Käynnistä, kirjoita "gpedit.msc" ja valitse sitten tuloksena oleva merkintä.

Siirry kohtaan Paikallinen tietokonekäytäntö > Tietokoneen asetukset > Windowsin asetukset > Suojausasetukset > Paikalliset käytännöt > Tarkastuspolitiikka. Kaksoisnapsauta oikeanpuoleisessa ruudussa "Tarkista kirjautumistapahtumat" ja valitse sitten Success and Failure ja paina sitten OK.

Voit tarkastella näitä tapahtumia siirtymällä Tapahtumanvalvontaohjelmaan ja sitten Windowsin lokit > Turvallisuus. PaperCut-palveluiden onnistuneen kirjautumisyrityksen lokissa pitäisi olla neljä tapahtumaa:

Jos todennusyritykset eivät pääse suojauslokiin, asiakasjärjestelmäsi on todennäköisesti osoitettu väärään toimialueen ohjaimeen.

Tarkista sovelluspalvelimen IP-protokollaasetukset:

Suorita ipconfig /all sovelluspalvelimella selvittääksesi, osoittaako se organisaation DNS-IP-osoitteeseen. Jos toimialueen DNS-IP-osoite puuttuu, sinulla on huono aika muodostaa yhteyksiä toimialueen ohjaimeen, mikä vaikuttaa kykyysi todentaa käyttäjiä sovelluspalvelimen kautta.

Kokeile suorittaa 'nltest'

Suorita C:\Windows> nltest /sc_query:DOMAINNAME.COM

Onnistunut suojattu kanavayhteys toimialueen ohjaimeen näyttää tältä:

Jos sinulla ei ole tuloksia suojatulle kanavalle, aloita vianetsintä perusasioista:

onko verkkokorttini kytketty? Onko minulla kelvollinen IP?Voinko pingata mitään sovelluspalvelimen ulkopuolelta? Onko minulla DNS-palvelimen IP-osoitteet määritetty? Vastaavatko dns-palvelimet? (testaa seuraavasti: nslookup -type=soa test.com, korvaa test.com Active Directory -verkkotunnuksesi dns-nimellä, joka on luultavasti ipconfig /all -tiedoston Primary Dns Suffix -rivillä lueteltu)

Korjaa yhteys tarvittaessa

Voit korjata sovelluspalvelimen verkkotunnuksen yhteyden käynnistämättä uudelleen: käytä PowerShell-komentoa Test-ComputerSecureChannel ja –credential –Repair-vaihtoehtoja. Tutustu Microsoftin Test-ComputerSecureChannel-dokumentaatioon.

Suorita komento, kirjaudu ulos ja kirjaudu sitten takaisin sisään verkkotunnuksen tunnistetiedoilla.

Jos haluat esimerkiksi korjata suhteen test.paper.com-verkkotunnuksen kanssa, anna komento:@@Test-ComputerSecureChannel –credential test.paper.com\Administrator –Repair

Muista, että vain Powershell 3.0:ssa ja uudemmissa on -credential-vaihtoehto Test-ComputerSecureChannelille.

Jos kaikki muu epäonnistuu…

Yritä yhdistää sovelluspalvelin uudelleen verkkotunnukseen. Tämä on tuskallisempi vaihtoehto, mutta kun asiat eivät vain näytä toimivan oikein, se voi joskus pelastaa päivän.

Kuinka PaperCut-käyttäjätodennus toimii Windows Active Directory -synkronointilähteen kanssa

Sovelluksen käyttäjän todennus riippuu Microsoft NTLM -protokollasta, joka tunnetaan myös nimellä Windows Challenge/Response. Alla oleva todennustyönkulku on mukautettu KB-artikkelista Microsoft NTLM.

NTLM käyttää salattua haaste/vastausprotokollaa käyttäjän todentamiseen lähettämättä käyttäjän salasanaa langattomasti. Sen sijaan todennusta pyytävän sovelluspalvelimen on suoritettava laskelma, joka osoittaa, että sillä on pääsy suojattuihin NTLM-tunnistetietoihin.

Vuorovaikutteinen NTLM-todennus PaperCutin kanssa sisältää kolme järjestelmää: käyttäjäasiakasjärjestelmän (sulautettu laite, Mobility-asiakas, PaperCut-ohjelmistoasiakas, käyttäjien verkkosivut), sovelluspalvelimen, jolle käyttäjä pyytää todennusta, ja toimialueen ohjaimen, jossa tietoja käyttäjän salasanaan liittyvät tiedot säilytetään. PaperCut-todennustyönkulkua kutsutaan muuten ei-vuorovaikutteiseksi todennuksena.

Ensimmäinen vaihe tarjoaa käyttäjän NTLM-tunnistetiedot

Käyttäjä käyttää asiakasjärjestelmää (kuten yllä on kuvattu) ja antaa käyttäjätunnuksen ja salasanan. Asiakasjärjestelmä lähettää käyttäjätunnuksen sovelluspalvelimelle selkeänä tekstinä. Muista kuitenkin, että PaperCut-asiakasjärjestelmät päivittävät automaattisesti todennusyhteydensä App Serveriin HTTP:stä HTTPS:ään, joten salasanat eivät kulje verkon läpi salaamattomana lukuun ottamatta yhtä poikkeusta: todennusyritykset käyttäjän tai järjestelmänvalvojan verkkosivujen kautta HTTP://-protokollaa käyttäen. URL HTTPS:// sijaan. Joka tapauksessa sovelluspalvelin laskee salasanan kryptografisen tiivisteen ja hylkää todellisen salasanan. Verkkotunnuksen ohjain luo 16-tavuisen satunnaisluvun, jota kutsutaan haasteeksi tai nonce-numeroksi, ja lähettää sen sovelluspalvelimelle. Sovelluspalvelin salaa tämän haastaa käyttäjän salasanan hajautusarvon ja palauttaa tuloksen Domain Controllerille. Tätä kutsutaan vastaukseksi. Sovelluspalvelin lähettää seuraavat kolme kohdetta toimialueen ohjaimelle: Käyttäjänimi, haaste ja vastaus Toimialueen ohjain käyttää käyttäjänimeä käyttäjän salasanan hajautukseen Security Account Manager -tietokannasta. Se käyttää tätä salasanahajautusta haasteen salaamiseen. Toimialueen ohjain vertaa laskemaansa salattua haastetta (vaiheessa 5) sovelluspalvelimen laskemaan vastaukseen (vaiheessa 3). Jos ne ovat identtisiä, todennus onnistuu.

Onko sinulla vielä kysyttävää?

Kerro meille! Rakastamme keskustella siitä, mitä konepellin alla tapahtuu. Voit vapaasti jättää kommentin alle tai vierailla tukiportaalissamme saadaksesi lisäapua.

Luokat: Vianetsintäartikkelit, Todennus

Avainsanat: kirjautumisvirhe, todennusvirhe, kirjautuminen, mainos, AD, aktiivinen hakemisto