Kerberos and NTLM are two authentication mechanisms used by Windows.
NTLM is Windows only, and Kerberos is RFC standard (RFC 1510), so it can be used by other platforms. NTLM is the default Windows authentication method before Windows 2000. As Kerberos has few enhancement over NTLM, so since Windows 2000, the windows client starts to use Kerberos as the preferred authentication protocol, although NTLM is still supported.
NTLM is supported by ios since iOS 2.0 (NSURLAuthenticationMethodNTLM)
Kerberos is supported by ios since iOS 7 with enterprise single sign on support.
For NTLM authentication, when client sends a request to server, if the server requires the NTLM authentication, the server will send 401 http status code to client. To handle it, the client will prompt user to input username and password, and then send back the credential information to server. Once the server gets the information it will talk to Windows Domain Controller to verify the user credential, and once verified a session cookie will return to client to indicate the authentication is succeeded. The key point is for NTLM, the web server will communicate with KDC using client provided credential to get a login token, so ios client does not need to know anything about the login secure server (KDC).
From the ios device side perspective, handling NTLM by application is no difference from handling regular 401 basic authentication. Once the challenge is received for NSURLAuthenticationMethodNTLM, then get the credential from user and send to server for authentication.
For Kerberos, the authentication is configured and handled on device level instead of application level, so once kerberos authentication is succeed, all applications installed on the device can share the authentication session with Single Sign On, so there is no need to authenticate each application separately. As for kerberos authentication, the device will directly communicate with KDC to get a login session, so the device must be configured for kerberos authentication to get the KDC information.
The main difference for Kerberos authentication is, the device will first contact domain controller using the username and password to get a ticket from KDC (Key Distribution Center), and once the ticket is available, any application installed on the device and configured to use Kerberos can use the ticket to authenticate itself when accessing a web resource, the resource server will communicate with domain controller to verify the client side ticket. So unlike NTLM, ios application implementation are transparent to Kerberos authentication and do not need to have any logic to retrieve the user credential and send it to KDC, all it needed is to include the app id in the kerberos device profile's AppIdentifierMatches field.
NTLM is Windows only, and Kerberos is RFC standard (RFC 1510), so it can be used by other platforms. NTLM is the default Windows authentication method before Windows 2000. As Kerberos has few enhancement over NTLM, so since Windows 2000, the windows client starts to use Kerberos as the preferred authentication protocol, although NTLM is still supported.
NTLM is supported by ios since iOS 2.0 (NSURLAuthenticationMethodNTLM)
Kerberos is supported by ios since iOS 7 with enterprise single sign on support.
For NTLM authentication, when client sends a request to server, if the server requires the NTLM authentication, the server will send 401 http status code to client. To handle it, the client will prompt user to input username and password, and then send back the credential information to server. Once the server gets the information it will talk to Windows Domain Controller to verify the user credential, and once verified a session cookie will return to client to indicate the authentication is succeeded. The key point is for NTLM, the web server will communicate with KDC using client provided credential to get a login token, so ios client does not need to know anything about the login secure server (KDC).
From the ios device side perspective, handling NTLM by application is no difference from handling regular 401 basic authentication. Once the challenge is received for NSURLAuthenticationMethodNTLM, then get the credential from user and send to server for authentication.
For Kerberos, the authentication is configured and handled on device level instead of application level, so once kerberos authentication is succeed, all applications installed on the device can share the authentication session with Single Sign On, so there is no need to authenticate each application separately. As for kerberos authentication, the device will directly communicate with KDC to get a login session, so the device must be configured for kerberos authentication to get the KDC information.
The main difference for Kerberos authentication is, the device will first contact domain controller using the username and password to get a ticket from KDC (Key Distribution Center), and once the ticket is available, any application installed on the device and configured to use Kerberos can use the ticket to authenticate itself when accessing a web resource, the resource server will communicate with domain controller to verify the client side ticket. So unlike NTLM, ios application implementation are transparent to Kerberos authentication and do not need to have any logic to retrieve the user credential and send it to KDC, all it needed is to include the app id in the kerberos device profile's AppIdentifierMatches field.
Do you know that Anegis microsoft axis one of the best consulting companies you can work with?
ReplyDeleteIn the process of company management, it is also worth using such tools that verify e-mail addresses. I recommend it for this purpose https://correct.email/
ReplyDelete