Odstraňování problémů s ověřováním služby Active Directory / přihlášením k AD...

„Pomoc! Moji uživatelé se nemohou přihlásit do uživatelského webového rozhraní PaperCut, klienta nebo mobilního tisku pomocí svých pověření domény Active Directory, ale interní uživatelské účty se mohou přihlásit v pohodě. Co se děje?"

Poznámka: Obecnější časté dotazy týkající se PaperCut a Active Directory naleznete v znalostní databázi Active Directory.

To může být problém, pokud jste svůj aplikační server PaperCut propojili tak, aby používal Active Directory jako zdroj uživatelského adresáře (podívejte se na Jak synchronizovat uživatele a skupiny s podrobnostmi Active Directory)…. a z nějakého důvodu již App Server nebude „mluvit“ s vaším Active Directory (AD).

Žádné interní uživatelské účty, které používáte, nebudou ovlivněny, protože ověření (a heslo) spravuje výhradně PaperCut. Ze stejného důvodu by vestavěný účet „admin“ také nebyl ovlivněn žádnými problémy s komunikací AD.

Zkontrolujte zřejmé věci

Je zapnutý numlock nebo caps lock? (Musíme se zeptat). Potvrďte, že problém se týká pouze účtů synchronizovaných s doménou. Zjistěte, zda se někdo může ověřit pomocí interního uživatelského účtu, jako je vestavěný správce (přihlášením do uživatelského webového rozhraní nebo tiskem přes Mobility). Pokud ano, problém se může týkat pouze účtů Windows Active Directory. Ujistěte se, že heslo pro účet, se kterým testujete, je naprosto správné. Co se stane, když resetujete heslo uživatele ve službě Active Directory a poté jej zkopírujete/vložíte na přihlašovací stránku uživatelského webového rozhraní?

Další řešení problémů

Ujistěte se, že na serveru PaperCut běží služba Netlogon< /h3>

Nejméně jeden zákazník nám dal vědět, že uživatelé domény přestali být schopni se ověřovat poté, co upgradovali svůj tiskový server Windows z roku 2012 na rok 2016. Problém se jim podařilo vyřešit podle kroků v tomto článku společnosti Microsoft o služba netlogon (viz část 'Řešení', která zdůrazňuje, jak změnit typ spouštění služby Netlogon na Automaticky a ujistěte se, že je služba spuštěna).

Článek také doporučuje restart serveru, i když to není nezbytně nutné.

Zkontrolujte protokoly zabezpečení systému Windows

Zkontrolujte, zda systém Windows vůbec zpracovává požadavky na ověření. Otevřete Editor místních zásad skupiny: stiskněte Start, zadejte „gpedit.msc“ a vyberte výslednou položku.

Přejít na Zásady místního počítače > Konfigurace počítače > Nastavení systému Windows > Nastavení zabezpečení > Místní zásady > Zásady auditu. V pravém podokně poklepejte na „Audit přihlášení události“, zaškrtněte Úspěch a neúspěch a stiskněte OK.

Chcete-li tyto události zobrazit, přejděte do Prohlížeče událostí a poté do Protokolů systému Windows > Bezpečnostní. Úspěšný pokus o přihlášení ke službám PaperCut by měl mít v protokolu čtyři události:

Pokud se pokusy o ověření nedostanou do protokolu zabezpečení, váš klientský systém pravděpodobně míří na nesprávný řadič domény.

Zkontrolujte nastavení protokolu IP na aplikačním serveru:

Spusťte ipconfig /all na aplikačním serveru a zjistěte, zda odkazuje na IP DNS organizace. Pokud chybí IP DNS domény, budete mít potíže s navazováním připojení k řadiči domény, což ovlivní vaši schopnost ověřovat uživatele prostřednictvím aplikačního serveru.

Zkuste spustit ‘nltest’

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

Úspěšné připojení zabezpečeného kanálu k řadiči domény by mělo vypadat takto:

Pokud pro zabezpečený kanál nemáte žádné výsledky, začněte odstraňování problémů se základy:

je moje síťová karta připojena? Mám platnou IP? Mohu pingnout cokoliv mimo App Server? Mám nakonfigurované IP servery DNS? Odpovídají DNS servery? (otestujte pomocí: nslookup -type=soa test.com, nahraďte test.com názvem DNS vaší domény Active Directory, což je pravděpodobně to, co je uvedeno v řádku Primary Dns Suffix v ipconfig /all)

Opravit připojení v případě potřeby

Připojení k doméně App Server můžete opravit bez restartování: použijte příkaz PowerShell Test-ComputerSecureChannel s možnostmi –credential –Repair. Podívejte se na dokumentaci Test-ComputerSecureChannel od společnosti Microsoft.

Spusťte příkaz, odhlaste se a poté se znovu přihlaste pomocí přihlašovacích údajů domény.

Chcete-li například opravit vztah s doménou test.paper.com, zadejte příkaz:@@Test-ComputerSecureChannel –credential test.paper.com\Administrator –Repair

Mějte na paměti, že pouze Powershell 3.0 a novější mají možnost -credential pro Test-ComputerSecureChannel.

Pokud vše ostatní selže…

Zkuste znovu připojit App Server k doméně. Toto je bolestivější možnost, ale když se zdá, že věci nefungují správně, může to někdy zachránit situaci.

Jak funguje ověřování uživatele PaperCut se zdrojem synchronizace Windows Active Directory

Ověření uživatele aplikace závisí na protokolu Microsoft NTLM, známém také jako Windows Challenge/Response. Níže uvedený pracovní postup ověřování je upraven z článku znalostní báze Microsoft NTLM.

NTLM používá k ověření uživatele šifrovaný protokol výzva/odpověď, aniž by bylo nutné posílat heslo uživatele po drátě. Místo toho musí App Server požadující ověření provést výpočet, který prokáže, že má přístup k zabezpečeným přihlašovacím údajům NTLM.

Interaktivní ověřování NTLM pomocí aplikace PaperCut zahrnuje tři systémy: uživatelský klientský systém (vestavěné zařízení, klient mobility, softwarový klient PaperCut, webové stránky uživatele), server aplikací, na který uživatel požaduje ověření, a řadič domény, kde jsou informace související s heslem uživatele je uchováván. Pracovní postup ověřování PaperCut je jinak známý jako neinteraktivní ověřování.

První krok poskytuje přihlašovací údaje NTLM uživatele

Uživatel přistupuje do klientského systému (jak je popsáno výše) a poskytuje uživatelské jméno a heslo. Klientský systém odešle uživatelské jméno na App Server v prostém textu. Mějte však na paměti, že klientské systémy PaperCut automaticky upgradují svá ověřovací připojení k App Serveru z HTTP na HTTPS, takže hesla nebudou procházet sítí nezašifrovaná s jedinou výjimkou: pokusy o autentizaci prostřednictvím webových stránek uživatele nebo správce pomocí HTTP:// URL místo HTTPS://. V každém případě, App Server vypočítá kryptografický hash hesla a zahodí skutečné heslo. Řadič domény vygeneruje 16bajtové náhodné číslo, nazývané výzva nebo nonce, a odešle je na App Server. App Server toto zašifruje. vyzvat hash hesla uživatele a vrátí výsledek řadiči domény. To se nazývá odpověď. Aplikační server odešle řadiči domény následující tři položky: Uživatelské jméno, Výzva a Odpověď Řadič domény používá uživatelské jméno k načtení hash hesla uživatele z databáze Security Account Manager. Tento hash hesla používá k zašifrování výzvy. Řadič domény porovná zašifrovanou výzvu, kterou vypočítal (v kroku 5), s odpovědí vypočítanou serverem App Server (v kroku 3). Pokud jsou identické, ověření je úspěšné.

Máte ještě nějaké otázky?

Dejte nám vědět! Rádi si povídáme o tom, co se děje pod kapotou. Neváhejte zanechat komentář níže nebo navštivte náš portál podpory pro další pomoc.

Kategorie: Články o odstraňování problémů, Ověřování

Klíčová slova: chyba přihlášení, chyba ověření, přihlášení, reklama, AD, aktivní adresář