Sökresultat :
×Kerberos är en kryptografibaserat autentiseringsprotokoll som skyddar åtkomsten till applikationer. Detta protokoll är utformat för att tillhandahålla säker autentisering över ett osäkert nätverk. Nyckelidén bakom Kerberos är att autentisera användare samtidigt som man förhindrar att lösenord skickas över internet.
Kerberos: Kerberos är ett autentiseringsprotokoll som stöder konceptet Single Sign-On (SSO). När det gäller HTTP tillhandahålls stöd för Kerberos vanligtvis med termen "SPNEGO"-autentiseringsmekanism.
Kerberos Realm: En administrativ domän för autentisering betecknas med termen sfär. Dess mål är att definiera begränsningarna för när en autentiseringsserver kan autentisera en användare, värd eller tjänst. Detta innebär inte att en användare och en tjänst måste vara medlemmar i samma sfär för att autentisering ska ske: om de två objekten är anslutna via en förtroendeanslutning trots att de tillhör olika sfärer kan autentisering fortfarande ske.
Rektor: I ett Kerberos-system representerar en Kerberos Principal en distinkt identitet till vilken Kerberos kan utfärda biljetter för åtkomst till Kerberos-medvetna tjänster. "/"-avgränsaren används för att separera de olika komponenterna som utgör huvudnamnen. Tecknet "@" kan användas för att identifiera en sfär som namnets sista element. Om ingen sfär är angiven, antas det att rektorn tillhör standardområdet som är inställd i filen krb5.conf.
Kunder/användare: en process som får åtkomst till en tjänst på uppdrag av en användare. Det kan finnas flera klienter eller användare inom en sfär.
Service: Något användaren vill få tillgång till.
SSO: Single Sign-On är en procedur som gör det möjligt för en användare att bara logga in en gång och få tillgång till många tjänster efter att ha slutfört användarautentisering. Efter att ha loggat in på en primär tjänst innebär detta autentisering i varje tjänst som användaren har gett behörighet till. SSO har ett antal fördelar, varav en är att undvika den tröttsamma processen att upprepade gånger validera identitet med hjälp av lösenord eller andra autentiseringssystem.
GSSAPI: Program kan komma åt säkerhetstjänster genom Generic Security Service Application Program Interface (GSSAPI), som är ett applikationsprogrammeringsgränssnitt (API). En IETF-standard är GSSAPI. Den erbjuder ingen säkerhet i sig. Istället erbjuds GSSAPI-implementeringar av leverantörer av säkerhetstjänster. Utbytet av ogenomskinliga meddelanden (tokens), som döljer implementeringsdetaljen från applikationen på högre nivå, är det utmärkande kännetecknet för GSSAPI-applikationer.
SPNEGO: Klient-serverprogramvara använder den enkla och skyddade GSSAPI-förhandlingsmekanismen, ofta kallad "spen-go", för att förhandla om valet av säkerhetsteknik. När en klientapplikation måste logga in på en fjärrserver men ingen ände är säker på vilka autentiseringsprotokoll den andra stöder, används SPNEGO. Pseudomekanismen använder ett protokoll för att identifiera de tillgängliga vanliga GSSAPI-mekanismerna, väljer en och tilldelar sedan alla efterföljande säkerhetsåtgärder till den valda mekanismen.
KDC: Ett nyckeldistributionscenter är en nätverkstjänst som tillhandahåller biljetter och tillfälliga sessionsnycklar; eller en instans av den tjänsten eller den värd som den körs på. KDC betjänar både initiala biljett- och biljettförfrågningar. Den initiala biljettdelen kallas ibland för autentiseringsservern (eller tjänsten). Den biljettbeviljande biljettdelen hänvisas ibland till som den biljettbeviljande servern (eller tjänsten).
En klients åtkomst till en resurs på en Active Directory-domän kan autentiseras med hjälp av autentiseringsprotokollet för utmaningssvar som kallas Windows NT LAN Manager (NTLM). När en klient begär åtkomst till en domänrelaterad tjänst, skickar tjänsten en utmaning till klienten och instruerar den att använda sin autentiseringstoken för att utföra en matematisk operation och sedan tillhandahålla resultatet till tjänsten. Resultatet kan verifieras av tjänsten eller verifieras av domänkontrollanten (DC). Tjänsten ger åtkomst till klienten om DC eller tjänsten verifierar att klientens svar är korrekt.
Eftersom det tillåter användaren att endast ange den underliggande autentiseringsfaktorn en gång, under inloggning, är NTLM en sorts enkel inloggning (SSO).
ktpass -princ HTTP/<Server Host Name>@EXAMPLE.COM -mapuser <username@EXAMPLE.COM>
-pass password -ptype KRB5_NT_PRINCIPAL -out <PATH>\spn.keytabNotera: Se till EXAMPLE.COM ska stå med versaler. Om användaren med SPN redan finns, använd den användaren för att skapa en ny. Kerberos-principen är skiftlägeskänslig. Kontrollera om det finns skillnader i versaler/gemener innan du kör tangentbordskommandot.
| Serverns värdnamn: | Det är värdnamnet för webbplatsen som finns på servern. |
| EXAMPLE.COM: | Det är Active Directory-domännamnet. |
| Användarnamn: | Det är ett tjänstekonto i Active Directory. |
| Lösenord: | Det är lösenordet för tjänstekontot som används ovan. |
| Väg: | Sökväg till en lokal plats som lagrar keytab-filen. (C:\Temp\spn.keytab) |
Notera: Kommandot ovan skapar en keytab-fil. Den måste placeras på klientservern där din WordPress-webbplats finns. Användaren som kör Apache bör ha full åtkomst till den här filen. Användaren bör ha behörighet till keytab-filen.
chmod 644 etc/apache2/spn.keytab
sudo apt-get install krb5-user
Notera: I de senaste utgåvorna av Ubuntu/Debian, mod_auth_kerb har föråldrats och ersatts med mod_auth_gssapi.
sudo apt-get install libapache2-mod-auth-kerba2enmod auth_kerbsudo apt-get -y install libapache2-mod-auth-gssapi
[libdefaults]
default_realm = EXAMPLE.COM
# ...
# ...
[realms]
EXAMPLE.COM = {
kdc = <DNS entries pointing to your primary domain controller>: Port
admin_server = <DNS entries pointing to your primary domain controller>: Port
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
Notera: Ersätt AD DOMAIN CONTROLLER IP/DNS med din IP/DNS-adress. Säkerställa EXAMPLE.COM ska stå i versaler.
Ersätt EXAMPLE.COM med Active Directory-domännamnet.
Och se till att port 88 på AD Domain Controller är åtkomlig från denna server.
Notera: Lägg till följande avsnitt i katalogen enligt vilken apache-modul som används. T.ex: "mod_auth_kerb" or "mod_auth_gssapi".
<Directory "/placeholder">
AuthType Kerberos
KrbAuthRealms EXAMPLE.COM
KrbServiceName HTTP/<Server Host Name>
Krb5Keytab <PATH TO KEYTAB>
KrbMethodNegotiate on
KrbMethodK5Passwd on
require valid-user
</Directory>
<IfModule !mod_auth_gssapi.c>
LoadModule auth_gssapi_module /usr/lib64/httpd/modules/mod_auth_gssapi.so
</IfModule>
<Directory "/placeholder">
AuthType GSSAPI
AuthName "Kerberos auth"
GssapiAllowedMech krb5
GssapiBasicAuth On
GssapiCredStore keytab:<PATH TO KEYTAB>
GssapiLocalName On
BrowserMatch Windows gssapi-no-negotiate
Require valid-user
</Directory>
Notera: Se till EXAMPLE.COM ska stå i versaler.
Följande är komponenterna i ovanstående konfiguration:
| EXAMPLE.COM: | Detta är Active Directory-domänen som konfigurerats i krb5.conf. |
| SÖG TILL TANGENTTABB: | Tillgänglig sökväg till tangentbordet på den här servern. (etc/spn.keytab) |
När du har konfigurerat inställningarna, Klicka här för att konfigurera webbläsare för Kerberos SSO.
För att testa din Kerberos/NTLM SSO-konfiguration, klicka här.
För att felsöka eventuella fel, vänligen klicka här.
Om du inte har ett tjänstekonto, skapa ett nytt användarkonto (tjänstkonto) i Active Directory Users and Computers. Se till att det här objektet inte har några SPN-poster (attributet servicePrincipalName ska vara tomt) tilldelade.
ktpass -princ HTTP/<Server Host Name>@EXAMPLE.COM -mapuser <username@EXAMPLE.COM>
-pass password -ptype KRB5_NT_PRINCIPAL -out <PATH>\spn.keytabOBS: Se till EXAMPLE.COM ska stå med versaler. Kerberos-principen är skiftlägeskänslig. Kontrollera om det finns skillnader i versaler/gemener innan du kör tangentbordskommandot.
| Serverns värdnamn: | Det är värdnamnet för webbplatsen som finns på servern. |
| EXAMPLE.COM: | Det är Active Directory-domännamnet. |
| Användarnamn: | Det är ett tjänstekonto i Active Directory. |
| Lösenord: | Det är lösenordet för tjänstekontot som används ovan. |
| Väg: | Sökväg till en lokal plats som lagrar keytab-filen. (C:\Temp\spn.keytab) |
Notera: Kommandot ovan skapar en keytab-fil. Den måste placeras på klientservern där din WordPress-webbplats finns. Användaren som kör Apache bör ha full åtkomst till den här filen. Användaren bör ha behörighet till keytab-filen.
chmod 644 etc/httpd/spn.keytab
yum install -y krb5-workstation krb5-devel krb5-libs mod_auth_gssapi mod_sessionNotera: I de senaste versionerna av CentOS, mod_auth_kerb har föråldrats och ersatts med mod_auth_gssapi.
yum install mod_auth_kerbsudo apt-get -y install libapache2-mod-auth-gssapi
default_realm = EXAMPLE.COM
dns_lookup_realm = true
dns_lookup_kdc = true
EXAMPLE.COM = {
kdc = <DNS entries pointing to your primary domain controller>: Port
admin_server = <DNS entries pointing to your primary domain controller>: Port
}
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
Notera: Ersätt AD DOMAIN CONTROLLER IP/DNS med din IP/DNS-adress. Säkerställa EXAMPLE.COM ska stå i versaler.
Ersätt EXAMPLE.COM med Active Directory-domännamnet.
Och se till att port 88 på AD Domain Controller är åtkomlig från denna server.
<Directory "/placeholder">
AuthType Kerberos
KrbAuthRealms EXAMPLE.COM
KrbServiceName HTTP/<Server Host Name>
Krb5Keytab <PATH TO KEYTAB>
KrbMethodNegotiate on
KrbMethodK5Passwd on
require valid-user
</Directory>
LoadModule auth_gssapi_module modules/mod_auth_gssapi.so
<Directory "/placeholder">
AuthType GSSAPI
AuthName "Kerberos auth"
GssapiBasicAuth On
GssapiCredStore keytab:<PATH TO KEYTAB>
GssapiLocalName On
Require valid-user
</Directory>
Följande är komponenterna i ovanstående konfiguration:
| VÄG TILL KEYTAB | Tillgänglig sökväg till tangentbordet på den här servern. (etc/apache2/spn.keytab) |
| "/Platshållare" | Sökväg till dokumentroten |
När du har konfigurerat inställningarna, Klicka här för att konfigurera webbläsare för Kerberos SSO.
För att testa din Kerberos/NTLM SSO-konfiguration, klicka här.
För att felsöka eventuella fel, vänligen klicka här.
Notera: Anta att webbplatsen måste svara på http://maskinnamn och http://maskinnamn.domän.com. Vi måste ange dessa adresser i SPN-attributet för tjänstekontot.
Setspn -S http/<computer-name>.<domain-name> <domain-user-account>Exempelvis: C:\Users\Administrator> setspn -S HTTP/maskinnamn.domän.com tjänstekonto
Notera: "maskinnamn.domän.com" här är datornamn. Se till att det går att lösa på Windows-servern som kör AD-tjänsten.
setspn -l domain or service_accountExempelvis: C:\Users\Administrator> setspn -l service_account eller C:\Users\Administrator> setspn -l domän namn
Notera: Som standard finns det två tillgängliga leverantörer, Negotiate och NTLM. Negotiate är en behållare som använder kerberos som den första autentiseringsmetoden, och om autentiseringen misslyckas används NTLM. Så det krävs att Negotiate kommer först i listan över leverantörer.
Exempelvis:domain.com\service_account
Notera: Att ställa useAppPoolCredentials till True innebär att vi tillåter IIS att använda domänkontot för att dekryptera Kerberos-biljett från klienterna.
Starta spelman och starta webbläsaren till önskad webbplats. Leta upp raden för webbplatsåtkomst i fönstrets vänstra sida. Välj fliken Inspektera från fönstrets högra sida. Det är uppenbart att Kerberos har använts för att autentisera på IIS-webbplatsen från raden "Authorization Header (Negotiate) seems to contain a Kerberos-ticket."
När du har konfigurerat inställningarna, Klicka här för att konfigurera webbläsare för Kerberos SSO.
För att testa din Kerberos/NTLM SSO-konfiguration, klicka här.
För att felsöka eventuella fel, vänligen klicka här.
Setspn -s http/<computer-name>.<domain-name> <domain-user-account>Exempelvis: C:\Users\Administrator> setspn -S HTTP/maskinnamn.domän.com tjänstekonto
Obs: "maskinnamn.domän.com" här är datornamn. Se till att det går att lösa på Windows-servern som kör AD-tjänsten.
setspn -l domain\service_account
LoadModule authnz_sspi_module modules/mod_authnz_sspi.soLoadModule authn_core_module modules/mod_authn_core.so
LoadModule authz_core_module modules/mod_authz_core.so
<Directory "...../xampp/htdocs">
......
......
#Require all granted
AllowOverride None Options None
AuthType SSPI
SSPIAuth On
SSPIAuthoritative On
Require valid-user
</Directory>
När du har konfigurerat inställningarna, Klicka här för att konfigurera webbläsare för Kerberos SSO.
För att testa din Kerberos/NTLM SSO-konfiguration, klicka här.
För att felsöka eventuella fel, vänligen klicka här.
Konfigurationen på klientsidan gör det möjligt för respektive webbläsare att använda SPNEGO för att förhandla fram Kerberos-autentisering för webbläsaren. Du måste se till att webbläsaren på en slutanvändares system är konfigurerad för att stödja Kerberos-autentisering.
Som standard kommer de allmänna webbläsarkonfigurationsinställningarna att vara tillämpliga, inga fler ytterligare inställningar krävs för Internet Explorer.
Som standard är de allmänna webbläsarkonfigurationsinställningarna tillämpliga, inga fler ytterligare inställningar krävs för Google Chrome.
Kerberos-protokollet kräver att tiden för klienten och servern matchar: om klientens systemklocka inte matchar serverns, kommer autentiseringen att misslyckas. Det enklaste sättet att synkronisera systemklockorna är att använda en NTP-server (Network Time Protocol).
För att verifiera din keytab- och kerberos-konfiguration kan du köra följande kommandon:
Kommandot klist visar innehållet i en Kerberos autentiseringscache eller nyckeltabell. Med detta kommando kan du kontrollera om du har en giltig biljett eller inte.
För att lista alla poster i nyckeltabellen etc/apache2/spn.keytab med tidsstämplar.
Visar krypteringstypen för sessionsnyckeln och biljetten och listar posterna i en nyckeltabell.
Verifiera Kerberos-autentisering med keytab-fil.
Du kan använda detta kommando på Linux för att återställa alla Kerberos-token på din lokala dator. Kommandot förstör din tidigare Kerberos-biljett.
Du kan använda detta kommando på Windows för att återställa alla Kerberos-token på din lokala dator. Kommandot förstör din tidigare Kerberos-biljett.
<?php
var_dump($_SERVER);
?>
Notera: Ta bort test.php-filen efter att ha verifierat din konfiguration. Eftersom den innehåller värdefull information.
ktutil
ktutil: read_kt <keytab_filename_1>
ktutil: read_kt <keytab_filename_2>
ktutil: read_kt <keytab_filename_3>
ktutil: write_kt spn.keytab
ktutil: quit
klist -k spn.keytab
kinit: Pre-authentication failed: Invalid argument while getting initial credentials
ktutil
addent -password -p HTTP/<Server Host Name>@EXAMPLE.COM -k 1 -e aes256-cts-hmac-sha1-96
wkt spn.keytab.
Unspecified GSS failure. Minor code may provide more information (Clock skew too great)
or
kinit: krb5_get_init_creds: Too large time skew
gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information (, Permission denied)
gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information (, Key table entry not found).
Warning: received token seems to be NTLM, which isn't supported by the Kerberos module. Check your IE configuration.
gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error)
gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information (, ).
kinit: KDC has no support for encryption type while getting initial credentials
[libdefaults]
default_tgs_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5
default_tkt_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5
kinit: krb5_get_init_creds: Error from KDC: CLIENT EXPIRED
or
kinit: Client's entry in database has expired while getting initial credentials
kinit: krb5_cc_get_principal: No credentials cache file found
or
kinit: krb5_get_init_creds: Error from KDC: CLIENT_NOT_FOUND
kinit : Cannot find KDC for requested realm while getting initial credentials
kinit: Preauthentication failed while getting initial credentials
kinit: Client not found in Kerberos database while getting initial credentials
kinit: Client's entry in database has expired
Behövs hjälp? Vi är här!
