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
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
I have windows server running ADFS server. I want to Connect to ldap server on it. My questions are
Does running ADFS Server already have LDAP Server running or need to do anything for that? I believe it is running already because I could see open port 389 and 636.
Assuming LDAP server is running, I was trying to connect to it using Google App Directory Sync to get list of users However I was not able to authorize. Is there any default credentials to connect? Or steps to get credentials for LDAP server?
Thanks
An ADFS server is not an Active Directory server - ADFS only extends Active Directory's infrastructure. Ports 389 and 636 are available because ADFS supports the LDAP and LDAPS protocols for communication, and as such, ADFS can retrieve user attributes from Active Directory, and it can also authenticate users against Active Directory. If you already have a directory server running, you need to add it to ADFS as an account store.
There are no default credentials - just use an administrative account that exists in your Active Directory store, as mentioned in point one.
To clarify on terminology for ADFS:
Account Store in ADFS: This is the account store that ADFS authenticates the user against with some form of credential (e.g. Username/password). By default ADFS connects to the Active Directory Domain Services and adds it as a special account store that cannot be deleted. So, any users in this active directory forest or in it's trusted subsystem can authenticate to ADFS. So far, ADFS only supported Active Directory as an account store and nothing else. With Windows Server 2016, it now supports connecting any LDAP v3 compliant directory as an account store. ADFS does not open LDAP ports as it is not an LDAP server. If ADFS were collocated with a domain controller, you would see LDAP ports open.
Attribute Store in ADFS: This a store where you can augment additional information about the user AFTER the user authenticates. By default ADFS has a default attribute store for ADDS that is setup by virtue of the install. Beyond this, it has in-built adapters that can be instantiated to connect to SQL or ADLDS (lightweight directory service). It also has an extensible API to connect to any other attribute store of your choice via .NET. People connect to Oracle/SAP data base, FIM metaverse etc.
#Srikanth: You will use the ADFS claims language or the UI to query for additional data using the attribute store model. In the UI, you would see it when you configure the issuance authorization rules or the issuance claims rules.
Hope that helps
Sam (#MrADFS)
We have a 3rd party product that allows some of our users to manipulate data in a database (on what we'll call SvrSQL) via a website on a separate server (SvrWeb).
On SvrWeb, we have a specific, non-default website setup for this application so instead of going to http://SvrWeb.company.com to get to the website we use http://application.company.com which resolves to SvrWeb and the host headers resolve to the correct website.
There is also a specific application pool set up for this site which uses an Active Directory account identity we'll call "company\SrvWeb_iis". We're setup to allow delegation on this account and to allow it to impersonate another login which we want it to do. (we want this account to pass along the AD credentials of the person signed into the website to SQL Server instead of a service account.
We also set up the SPNs for the SrvWeb_iis account via the following command:
setspn -A HTTP/SrvWeb.company.com SrvWeb_iis
The website pulls up, but the section of the website that makes the call to the database returns the message:
Cannot execute database query.
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
I thought we had the SPN information set up correctly, but when I check the security event log on SrvWeb I see entries of my logging in, but it seems to be using NTLM and not kerberos:
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Any ideas or articles that cover this setup in detail would be extremely appreciated!
If it helps, we are using SQL Server 2005, and both the web and SQL servers are Windows 2003.
There are several possible reasons for kerberos failures which includes lack of SPN and duplicate SPN as well.
If SQL is running under custom account you would need to add SPN for SQL as well.
Also keep in mind, you should be adding SPN for the FQDN which is the host (A) entry in DNS and not a CNAME.
Check the value of NTAuthenticationProviders
http://support.microsoft.com/kb/215383
Try DelegConfig which would show what is missing if its SPN or something else.
http://www.iis.net/community/default.aspx?tabid=34&g=6&i=1887