Here made I some notes during configuration of Kerberos authentication on Dokuwiki web app via Active Directory, it was quite a big challenge for me :)
Kerberos is based on 3 things: key distribution server(KDC), kerberized server and client. For example let's look how it works in AD. In AD environment KDC is domain controller.
There are two abstraction layers to choose from: GSSAPI and SSPI. GSSAPI, or the “Generic Security Services API,” is the API provided by Unix-based Kerberos 5 implementations. SSPI, the “Security Support Provider Interface,” is Microsoft's answer to GSSAPI and, of course, available only for Windows 2000 and above.
Microsoft uses SPNEGO, the Simple and Protected Negotiation mechanism. SPNEGO provides a method where server and client can mutually negotiate the best authentication mechanism to use (in this case, NTLM and Kerberos). The use of SPNEGO for web-based authentication is referred to as the HTTP Negotiate protocol. Once the negotiation is finished, then the mutually agreed upon authentication mechanism can begin. In this case, we'll only be compatible with the Windows Kerberos authentication mechanism; it will fail if Windows attempts to use NTLM instead.
Links
Kerberos is based on 3 things: key distribution server(KDC), kerberized server and client. For example let's look how it works in AD. In AD environment KDC is domain controller.
There are two abstraction layers to choose from: GSSAPI and SSPI. GSSAPI, or the “Generic Security Services API,” is the API provided by Unix-based Kerberos 5 implementations. SSPI, the “Security Support Provider Interface,” is Microsoft's answer to GSSAPI and, of course, available only for Windows 2000 and above.
Microsoft uses SPNEGO, the Simple and Protected Negotiation mechanism. SPNEGO provides a method where server and client can mutually negotiate the best authentication mechanism to use (in this case, NTLM and Kerberos). The use of SPNEGO for web-based authentication is referred to as the HTTP Negotiate protocol. Once the negotiation is finished, then the mutually agreed upon authentication mechanism can begin. In this case, we'll only be compatible with the Windows Kerberos authentication mechanism; it will fail if Windows attempts to use NTLM instead.
When user enters domain, he recieves Ticket Granting Ticket(TGT). Whe he tries to enter web server with kerberos authentication, IE sends request HTTP/DNS_name_of_plug-in_server@Active_Directory_domain_name to domain controller. After this user gets Session Ticket, encrypted with password of user, that is bind to the service. Then this Session ticket would be sent to web server. Web server decrypts it with keytab file.
To see users binded to services this manual can be used: When multiple accounts are binded to one service
To bind user to service, ktpass command is used:
ktpass -out wiki.keytab -princ HTTP/wiki.test.ru@TEST.RU -mapuser fil -pass 123Links
- Kerberos Authentication in Windows Server 2003
- Kerberos explained
- Kerberos-Based SSO with Apache
- Using mod_auth_kerb and Windows 2000/2003 as KDC
- The Moron's Guide to Kerberos
- Kerberos: An Authentication Service for Computer Networks
- Kerberos FAQ
- Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability
- Practical Unix and internet security: Kerberos
- Linux-AD Integration with Windows Server 2008
- HTTP-Based Cross-Platform Authentication by Using the Negotiate Protocol