What I understand:
NTLMv1/v2 is a shorthand for Net-NTLMv1/v2 and hence are the same thing.
NTLM (without v1/v2) means something completely different.
NTLM hashes are stored in the Security Account Manager (SAM) database and in Domain Controller's NTDS.dit database.
Net-NTLM hashes are used for network authentication (they are derived from a challenge/response algorithm and are based on the user's NT hash).
Kerberos uses tickets to authenticate
My questions:
Why use NTLMv2 when you can use Kerberos instead for authentication (ie SMB)
Why does the account you want to log in needs an SPN for Kerberos? Can't you just use Kerberos for logging in any account?
Is NTLMv2 used for simply logging in accounts?
Is NTLMv2 used in SMB?
Kerberos is used in LDAP, right?
Heard Kerberos is used to retrieve resources from the domain controller, what are some resources?
Why is NTLMv2 still used, and where
Where is Kerberos used other than logging into accounts with SPNs
What does Kerberos really log you in? A shell? Account?
What does NTLMv2 really log you in? A shell? Account? File share?
What are SPNs, what are used for and where
There are far too many questions here to answer individually, so here is a better way to think about it.
NTLM is a p2p authentication protocol. The client sends a ticket directly to the server and the server can validate it directly or send it off to a a Domain Controller to validate. This is why workgroup PC to workgroup PC can succeed with just a username and password. However, with NTLM you have no way to prove the server you've sent the ticket to is actually the server you want to send it to. This means no server authentication, and therefore means no mutual authentication.
Kerberos always relies on a third server to authenticate you and the server you're trying to authenticate to. You do this by first authenticating to the KDC (Domain Controller), and then with that resultant ticket request a new ticket to the target service. The KDC uses the SPN to find the details of the target service in the directory and encrypts the identity to a key only the target service knows.
Then the client sends the new ticket to the target service, the service decrypts the ticket, and then encrypts a response to the client with a key shared in the encrypted ticket. Since only the named server can decrypt the ticket (and therefore see the shared encryption key), the client has evidence it's talking to the service with the given SPN. That provides server authentication, and therefore mutual authentication. If you don't have an SPN you can't ask the KDC to create a ticket that only the server knows.
If you don't have an SPN, there is a lesser known flow of Kerberos called user-to-user, which requires an out of band process to exchange additional tickets. This is rarely used because it's more complicated and just shifts the server auth problem.
This explains why both protocols exist. NTLM exists where there isn't a KDC, or the service isn't configured with an SPN. The downside is NTLM is less secure.
In Windows-land NTLM and Kerberos are mostly interchangeable because they're wrapped in a separate protocol called SPNEGO, which is an authentication negotiation protocol. Kerberos is usually tried first, and falls back to NTLM if Kerberos fails. In the majority of cases SPNEGO is used in place of Kerberos or NTLM so whether something uses Kerberos or NTLM is entirely dependent on whether the client can get a Kerberos ticket.
Kerberos is generally always attempted. When you log into your domain-joined machine Kerberos is always used. NTLM can be used without additional work because it is an artifact of the credentials you typed in.
Refer to the
https://learn.microsoft.com/en-us/dotnet/framework/network-programming/ntlm-and-kerberos-authentication
Kerberos: https://learn.microsoft.com/en-us/windows-server/security/kerberos/kerberos-authentication-overview
NTLM: https://learn.microsoft.com/en-us/windows-server/security/kerberos/ntlm-overview
What is NTLM?: It is an Authentication Protocol that is used in older versions of Windows. But it is still being used today world. If for any reason Kerberos fails to, NTLM will be used instead. NTLM stands for New Technology LAN Manager
What is Kerberos?: It is also an Authentication Protocol, it is a default authentication protocol on Windows version above Win2K, to replace the NTLM Auth protocol.
No
Kerberos
NTLM
1
Kerberos is an Open Source software and offers free services
NTLM is the proprietary Microsoft authentication protocol
2
Kerberos supports delegation of authentication in multi-tier application
NTLM does not support delegation of authentication
3
Kerberos supports two factor authentication such as smart card logon
NTLM does not support smart card logon
4
Kerberos has the feature of mutual authentication
NTLM does not have future of mutual authentication
5
It provides high security
While NTLM is less secured as compared to Kerberos
6
Kerberos is supported in Windows 2000, XP and later versions
NTLM is also supported in earlier windows versions of Windows 95, 98 ME, and NT 4.0
NTLM Authentication Illustration:
Kerberos Authentication Illustration:
Related
I have WS 2016 running as AD/DC on which NTLM/NTLMv2 is disabled (Kerberos is a way to go). I have successfully joined Ubuntu machine to it, using this tutorial "Integrate Ubuntu with AD". Everything if working correctly (except Samba), can view users and groups on AD and can login to Ubuntu machine using AD user.
Now when I try to login with AD user to samba share I get NT_STATUS_NTLM_BLOCKED, which is expected, sense NTLM is blocked by AD.
Now my question is how to setup (force) Samba to use kerberos instead NTLM ?
It sounds like you're thinking that the SMB server just receives your password and then uses either NTLM or Kerberos to validate it. That's not how it works.
In SMB, it's the client which speaks NTLM or Kerberos when connecting to the server. You cannot force the server to use Kerberos because that is not the server's decision; it can either offer Kerberos or not, but it cannot make the client support Kerberos if the client doesn't support it.
Most mobile SMB client libraries do not have any Kerberos support (due to complexity); they will only use NTLM.
My "solution" to this issue was simply to exclude specific server from NTLM restriction policy.
There are two policies, on active directory server, in "Local Group Policy/Computer Configuration/Windows Settings/Security Settings/Local Policies/Security options":
Network security: Restrict NTLM: Add server exceptions in this domain
Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication
So servers that are defined under those two policies are able to use NTLM.
Not a solution, but for now it's a workaround.
When a user logs in to a SSO (Single Sign on) application, IIS makes a request to LDAP (Lightweight Directory Access Protocol) to get some user information for authentication. I am trying to find where the communication between LDAP and IIS happens (I am assuming that IIS sends a request to LDAP in order to get some user information). I have looked in the IIS Manager in windows and could not find the communication between IIS and LDAP. Does anyone know where I would be able to find the communication between LDAP and IIS?
If you're talking about Windows Authentication, then no, IIS doesn't use LDAP. It will use either Kerberos (preferably) or NTLM.
The mechanism is different for each, but basically, the user is already logged in on the client computer and sends their already-existing ticket to the server. The server just verifies the ticket with the domain controller. This means that the server must be joined to the same domain (or a trusted domain) as the user logging in.
For seamless SSO (where the user does not need to type in their username/password), the user must be logged into the client computer with the credentials they want to use on the website. If not, they will be prompted for credentials and the actual logging in will happen from the server.
If you cannot use Windows Authentication because the server is not joined to the same (or trusted) domain as the user, then you would have to implement LDAP authentication yourself. You would use Forms Authentication, ask for the user's username and password, and validate the credentials like this for example.
I have a question about installing SQL server and a SP2016 development farm. I can install both but my boss asked me questions about installing SPN (Service Principal Name) in the AD. But I don't know why and how an SPN is linked with SQL and SharePoint.
I've done some research on the web and got some terms "Kerberos" but I installed SharePoint with NTLM. Help me understand why SPNs would be useful in this case.
What is a Service Principal Name?
The SPN represents the service entry point into your SQL server for clients to find (using DNS) when they will be using Kerberos authentication.
SPNs are written as a service followed by the fully-qualified DNS name of the IP host the service is running on, (and sometimes optionally, appended with the Kerberos realm name appended to the end). For example if your SQL server were named 'sqlserver1' and your AD domain name was 'acme.com' would be written as: MSSQLsvc/sqlserver1.acme.com.
The SPN itself is found inside the Kerberos database, and clients during the authentication process reach out to DNS to find the IP target host and the Kerberos database (KDC) holding the service principal, grab a Kerberos service ticket from the KDC and use that to single sign-on authenticate to the server running on the target service named in the SPN.
Configuring SPNs
In AD, in the properties of the computer object representing your SQL server, you will add the SPN, and optionally configure Kerberos delegation for that service. You could optionally add the SPN to a user account running the SQL service in AD instead.
In your scenario, Kerberos should actually be the primary authentication method, with NTLM used only as a fallback. If you setup up DNS, AD, Kerberos delegation and the target server correctly, you should never have to fallback to NTLM. With SharePoint, you would use Kerberos to SSO into SharePoint, and then you could optionally allow Kerberos delegation for that same user account to be able to run SQL statements own the SQL DB server as themselves.
None of this is for the faint of heart, and I have actually not setup this precise scenario myself, I just know the underlying concepts; instead my experience is mainly setting up Kerberos SSO to Active Directory authentication to web applications running on Linux platforms. But you asked what an SPN was for and that's what I've answered.
Further Reading
I googled and found this link for you for actually setting up your scenario, it talks about configuring SharePoint with Active Directory with SQL server using Kerberos delegation: Plan for Kerberos authentication in SharePoint 2013
We are configuring a Siebel to authenticate against a Microsoft Active Directory with Kerberos enabled.
Kerberos authentication is not enabled in Siebel under Unix so we're planning to use simple authentication.
It is possible to authenticate to a Microsoft Active Directory without Kerberos when Kerberos is enabled in the domain controller?
Best regards,
Yes, you can authenticate to a Microsoft Active Directory without Kerberos, using either NTLM or LDAP. NTLM though, is disabled by default in AD 2008 and above. LDAP authentication through bind calls can be used as well by application servers who can't do ether NTLM or Kerberos. Classically, LDAP is meant as a directory lookup protocol and not really meant as an authentication protocol. Typically, these scenarios involve application servers running on non-Microsoft platforms. Be advised that Kerberos is the most secure protocol of the three and is the industry standard for authentication.
When SSPI is in "negociate mode", NTLM seems to be the favorite one (a legacy story).
But when and why SSPI will consider (and pick) Kerberos ?
(As far as I can see, when a client and server are on the same machine, NTLM is picked out)
Kerberos is preferred over NTLM and used whenever it's possible, i.e:
client machine is logged into Active Directory
client machine can access DNS
DNS contains A record (not CNAME-alias) - for server, which client wants to access (both forward and backward), so that web browser could transform it into correct SPN
no duplicated SPNs
webserver runs on another machine than client webbrowser
there must be at least one encoding type, which both machines support (defined in krb5.ini)