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)
Related
i have configured kerberos authentication when accessing to file server.
there is no need for logging in when i map drive and acccess to the file server
Just a curious question, if i can add additional server name to be used for authentication
for example.
currently my file server name is server01
when i map network drive through server01 / IP address, there is no issue.
when i tried to access through a server name server02, then i get an error in mapping the drive.
is there any way i can do this by allowing multiple server name to be allowed for kerberos authentication ?
thanks in advance for any advise
You can map as many file shares as possible you want with Kerberos authentication on a Windows domain joined system if the file servers hosting the file shares are joined to the same domain as the client Windows system accessing them.
Thus, you may have multiple file servers in your domain environment but they all should be joined to the AD domain for the Kerberos authentication to work successfully and let the users accessing and mapping the file shares authenticate through it as Kerberos needs a KDC (Key Distribution Center) due to which Active Directory authentication is required.
Please find the below dependencies for Kerberos authentication to work successfully: -
Operating System --> Later then Windows 2000 for client and Windows 2003
TCP/IP Network Connectivity --> Should exist between DC, client, and the target server
Domain System --> DNS must be functioning and accessible for the client
Active Directory Domain --> Necessary to use Kerberos authentication
Time Service --> Time source should be same and synchronized on all the network computers
Service Principal Names --> Kerberos authentication needs to have an SPN set for it so that clients can identify the service on the network
Also, refer this document for more details.
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.
We are deploying a java application to RHEL 7.5, this java application need connect to SQL Server 2016. As security request, we must use integrated security to connect SQL Server 2016. Follow Microsoft website's suggestion, we are implementing Kerberos in Windows AD Server and RHEL 7.5.
Unfortunately, we are facing a credentials issue. klist command is working fine on RHEL 7.5, means Kerberos clinet which has installed in RHEL7.5 can talk to Kerberos Server(Windows AD server) as normal. And RHEL7.5 can ping / talnet AD Server and SQL Server.
we have followed Microsoft's spec to set SPN as following:
setspn -A HTTP/SERVER_01.devdc.local#DEVDC.LOCAL devdc.local\admin.
As microsoft's guideline, we should use MSSQLSvc not HTTP, but it has issue when we use MSSQLSvc, we think the reason is OS version of AD server is Windows Server 2012, so cannot support MSSQLSvc protocal. After change to HTTP, kerberos is working fine. Can use kinit generate ticket and use klist to see the ticket information.
Part of our Java code as below:
System.setProperty("java.security.krb5.conf", "~/krb5.conf");
SQLServerDataSource ds = new SQLServerDataSource();
ds.setServerName("192.168.100.150");
ds.setPortNumber(1234);
ds.setIntegratedSecurity(true);
ds.setAuthenticationScheme("JavaKerberos");
ds.setDatabaseName("DB_TEST");
The error details as following:
Error connection to database:(using class com.microsoft.sqlserver.jdbc.SQLServerDriver)
GSSException: No valid credentials provide (mechanism level: Server not found)
KrbException: Server not found in Kerberos database(7)
KrbException: Identifier doesn't match expected value(906)
I would be grateful if you can help.
You don't appear to be setting the SPN. See
A service principal name (SPN) is the name by which a client uniquely
identifies an instance of a service.
You can specify the SPN using the serverSpn connection property, or
simply let the driver build it for you (the default). This property is
in the form of: "MSSQLSvc/fqdn:port#REALM" where fqdn is the
fully-qualified domain name, port is the port number, and REALM is the
Kerberos realm of the SQL Server in upper-case letters. The realm
portion of this property is optional if your Kerberos configuration's
default realm is the same realm as that of the Server and is not
included by default. If you wish to support a cross-realm
authentication scenario where the default realm in the Kerberos
configuration is different than the realm of the Server, then you must
set the SPN with the serverSpn property.
For example, your SPN might look like:
"MSSQLSvc/some-server.zzz.corp.contoso.com:1433#ZZZZ.CORP.CONTOSO.COM"
Using Kerberos integrated authentication to connect to SQL Server - Service principal names.
The driver will attempt to build the SPN for you from the other connection attributes, but you've got an IP address instead of a FQDN, so it cannot build the correct SPN. In the default configuration SQL Server registers its own SPNs and you can see the correct SPN in the SQL Server log, but there are scenarios where additional SPNs must be registered for the service account, and you would need to use the setspn command on Windows to see them.
Assuming your SQL Server is listening on port 1234, and you haven't changed the service account for the SQL Server instance from the default, then the SPNs should be registered for the machine accoune, and the setspn statements should be:
setspn –A MSSQLSvc/SERVER_01.devdc.local devdc\SERVER_01$
setspn –A MSSQLSvc/SERVER_01.devdc.local:1234 devdc\SERVER_01$
if you've set a domain account as the service account, say devdc\sqlsvc then substitute that.
setspn –A MSSQLSvc/SERVER_01.devdc.local devdc\sqlsvc
setspn –A MSSQLSvc/SERVER_01.devdc.local:1234 devdc\sqlsvc
TL/DR use the SQL Server's fully-qualified domain name (FQDN) for setServerName() instead of an IP address. If that doesn't work, you'll have to ask your network security people what SPNs are registered for the SQL Server service account. If you give up on Kerberos, fall back to NTLM.
Also in the newer JDBC driver Microsoft has implemented NTLM, which is the other Windows Authentication protocol.
But be aware of the following security caveat:
The NTLM protocol is an old authentication protocol with various
vulnerabilities, which pose a security risk. It's based on a
relatively weak cryptographic scheme and is vulnerable to various
attacks. It's replaced with Kerberos, which is a lot more secure and
recommended. NTLM authentication should only be used in a secure
trusted environment, or when Kerberos can't be used.
The Microsoft JDBC Driver for SQL Server only supports NTLM v2, which
has some security improvements over the original v1 protocol. It's
also recommended to enable Extended Protection, or use SSL Encryption
for increased security.
Using NTLM Authentication to connect to SQL Server - Security risks
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:
Here's my connection string
Data Source=PNJK-SERVER;Initial Catalog=PNJKDC;Integrated Security=True
but when I deployed it to another computer this error appears --> http://prntscr.com/atlzdp
Possible cause of the error are:
1) It will cause error if you have different SQL Instance for the other computer which is 99% possible. So your instance for the other computer will also be changed, and make sure that the DB PNJKDC also exist in that computer
2) If you are connected to a network and let's say you configured the whole networking thing e.g.(firewall, ports) the port number might be used by other processes in your computer, you need to change it to different port.
I would suggest creating a new user on the deployed machine's sql server instance, assign the user then necessary permissions to this database instance and specify the use in the connection string: User Id=username;Password=password12 instead of Integrated Security=true;.
Data Source=PNJK-SERVER;Initial Catalog=PNJKDC;User Id=username;Password=password12;
You need to ensure that Mix Mode Sql Server authentication is enabled and not just Windows Authentication for Sql Server.
If it is on a domain then you require to create a domain service account (Windows Authentication) with the necessary permissions to run the application. This will allow Integrated Security=true to work in most cases.