I'm now kerberizing a cross-platform application with GSSAPI.
While I'm not clear about the difference between UPN and SPN.
The development environment is a Samba4 AD DC server on CentOS 6.4 with a Windows server 2008 R2 a member box in the domain, say EXAMPLE.COM (You may be curious why not use Win2008 as DC directly. And as I stated previously, the application is cross-platform, I'm now testing in this setting. The normal Win DC-Linux MEM setting works fine.).
I create a new user foobar:users to run the application.
When I use foobar#EXAMPLE.COM, i.e. the UPN, to authenticate the application against Kerberos, I keep receiving
Kerberos: Principal may not act as server ERROR
Following a thread on Samba maillist, I think I should create a service principal name say app/dc.example.com for the UPN with samba-tool
samba-tool spn add app/dc.example.com foobar
This time I will receive another error
Samba4 KDC - no such entry found in hdb
My question is what's the difference between a UPN and SPN?
By samba-tool spn list foobar, it says foobar has servicePrincipalName app/dc.example.com.
How could I associate a UPN with an SPN?
Thank you very much.
Simply put,
UPN: An entity performing client requests to some service. Entity may be human or machine. See here.
SPN: An entity processing requests for a specific service, e.g., HTTP, LDAP, SSH, etc. Machine only. See here.
A UPN retrieves a service ticket for an SPN to use that actual service.
If your samba-tool call your request samba to register the SPN app/dc.example.com to the UPN foobar. Since You have not provided the realm of the SPN and UPN, Samba will assume the default realm of the machine this call is performed from. In Windows terms, you mostly bind an SPN to a machine UPN. Which is always: <name>$#<REALM>. Note the dollar sign.
Related
Calling all Windows Experts :).
After a long time of testing, i was able to get ADFS4.0 working with a thirdparty application.
I can successfully navigate to thirdparty application, click login and get redirected to my adfs federation domain and be prompted for login, login without issues, then be logged into thirdparty site.
I went through various different articles regarding ADFS integrating with IWA and no matter what configurations I have made, I continue to get asked for a login which I do not want.
Brief walkthrough of my current setup. Note, they are not the real names but i thought i would make it easier naming them as to give you an idea as to how my settings are currently.
ADCS Server that just hosts a Cert. adcs.dctestdomain.local
Domain Controller that hosts a test domain dc.dctestdomain.local
ADFS server = adfs.dctestdomain.local. Federation server farm is adfs.publicdomain.com
I have followed the following:
https://help.hcltechsw.com/domino/11.0.1/admin/secu_creating_the_spn.html
host/adfs.publicdomain.com dctestdomain.local\SSOTest
spn = http/adfs.publicdomain.com dctestdomain.local\SSOTest
https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/troubleshooting/ad-fs-tshoot-iwa
https://help.hcltechsw.com/domino/11.0.1/admin/secu_enabling_iwa_adfs30.html
`Set-ADFSProperties -WIASupportedUserAgents #("MSIE 6.0", "MSIE 7.0", "MSIE 8.0", "MSIE 9.0", "MSIE 10.0", "MSIE 11.0", "Trident/7.0", "MSIPC", "Windows Rights Management Client", "Mozilla/5.0")`
https://help.hcltechsw.com/domino/11.0.1/admin/secu_enabling_iwa_adfs30.html
Made the appropriate changes in the adfs server and the VM that is testing the adfs logins
Other things I have done:
nslookup -debug adfs.publicdomain.com shows that there is an A record and not a cname
(Get-AdfsProperties).WiaEvaluationMethod returns: WiaUserAgentDetection
`Get-ADObject -LDAPFilter "(|(ServicePrincipalName=http/adfs.publicdomain.com(servicePrincipalName=host/adfs.publicdomain.com )"`
Value shown is somewhere along these lines:
`CN=SSOTest,CN=Managed Service Accounts,DC=omitted,DC=omitted SSOTest msDS- GroupManagedServiceAccount`
`Set-AdfsProperties -ExtendedProtectionTokenCheck None`
Set the fqdn farm in the intranet zones, selected automatic logon with username and password(also tried intranet only) neither work
set Automatically detect intranet network
Set the public domain name in the trusted internet zones and set the same settings for testing purposes.
There is no load balancer
Everytime I get redirected from the 3rd Party site, I still have to log in to ADFS. Does anyone know what the problem may be? For security reasons, I did not provide real domains or account names but I think I have provided the best possible info. If you need more, please let me know. Any help would be greatly appreciated.
I have setup Kerberos following below document
http://docs.hortonworks.com/HDPDocuments/Ambari-2.2.0.0/bk_Ambari_Security_Guide/content/ch_configuring_amb_hdp_for_kerberos.html
Further, I would like to configure ranger to sync all Kerberos principals to create ACLS. There is an option to sync users from AD but I don't see any option to sync from Kerberos. See options in image below
Can anyone please help with options for doing this. Thanks
I'm not sure I understand what exactly you want to import, but I assume you have AD and local cluster KDC which are configured with trusted relations and you want all your principles to be represented in Ranger by standalone user accounts. If you have trusted relations configured that means that your entire list of principles would consist of both local KDC and AD and they all would be valid for authentication. But in ranger you work not with the actual Kerberos principles, but with the usernames, which are obtained from auth_to_local configuration setting according to the mapping rules specified there.
If you are running LDAP sync, it will pass all matching principles through the collection of rules in this configuration property and will create the end user account with names obtained after execution of these rules. You can check the end results using:
hadoop org.apache.hadoop.security.HadoopKerberosName principle#domain.com
For local KDC it really does not make sense to pass the principles from KDC through this mapping stage as at the end they all will be mapped to local UNIX accounts. That is why you can just point your group and passwd files in UNIX sync source and you can assume that all your local Kerberos principles would be represented in the Ranger database with proper user accounts.
You can find some more details about the aspects of Kerberos mappings in this article
Goal: Give users an account (domain user or basic, doesn't matter) and have them use Get-DhcpServerv4Lease cmdlet to convert their DHCP leases to reservations via the powershell web access feature using a web browser.
Issue/problem: I already made my own AuthorizationRule by importing that specific cmdlet but I feel like its missing others modules in order to authenticate/login? I can login if I grant microsoft.powershell configurationrule but cant if I grant the custom one that I made.
Error received upon login with my own custom configuration:
The Windows PowerShell Web Access gateway cannot establish a connection to the destination computer. Contact the gateway administrator. The error at the gateway is: The WS-Management service cannot process the request. The service is configured to reject remote connection requests for this plugin.
Question: Is there some other module I need to add to my custom rule or maybe there is a way to know what permissions microsoft.powershell contains so that I could mirror/copy them into my own rule?
Thanks
The quick answer: Remote Powershell needs to be enabled on the target system!
You can use System names, IP addresses or the FQDN. All of them will work (Use a mix as well)
To keep your Rules simple: Use Groups! Here is a Gist that could help you a bit. I have just a few rules and use AD Groups to manage the access (Systems and Users)
Please execute this (in an elevated PowerShell): Enable-PSRemoting -Force
You have to do this on all systems that you would like to access via the Web Gateway.
You will find a lot more Info about this on TechNet.
Searching around the windows authentication methods and protocols, i decided to understand the exact difference between Negotiate, Kerberos, and NTLM used in a simple executable file before liking it with IIS and Web Authentication.
I reached to good results, BUT I still need more details about the Negotiate and Kerberos.
I have the following scenario :
I have created very simple C# windows forms application that shows a message box displays the value for :
System.Security.Principal.WindowsIdentity.GetCurrent().AuthenticationType
Note that i'm a domain user with admin privileges on my local machine, I have the following results :
When i run the exe file (double click) while i'm actively connected to the DC, i got "Negotiate".
When i run the exe file (run as differnet user / using local user) while i'm actively connected to the DC, i got "NTLM".
When i run the exe file using "Run as Administrator", or "Run as Different User" i got "Kerberos".
When i run the exe file while i'm locally logged in using local account, i got "NTLM".
I understand that the LSA will use NTLM for local accounts. Also i understand that Active Directory uses Kerberos to authenticate domain users and computers.
My question is, why i'm getting the Negotiate Authentication Type when i run the exe using my account either by (Double Click), or "run as different user" using my Same account ?
Update : I noticed the following :
- If local user is running the exe then it is NTLM
- If domain user run the exe then it is Negotiate (If that user is local admin) but is is Kerberos (if that user is not local admin)
- If domain admin run the exe then it is Kerberos
I just a clarification about this behavior.
First off, (which you seem to understand in the question, but just to be clear) an EXE doesn't have any authentication - it is just an executable. The OS creates a process object which executes it within a logon session identified by a principal. It's this principal which has been authenticated by NTLM or Kerberos (or some other protocol).
Next, Negotiate means that when the logon session was created the Negotiate authentication package was used to decide which authentication package - Kerberos or NTLM - would be used.
When you query the WindowsIdentity.AuthenticationType value, you are ultimately calling a function in the Local Security Authority (LSA) called LsaGetLogonSessionData. This reports details of the logon session used to run the process you are executing. The way that this logon session was created probably has the largest effect on the authentication package used to verify the credentials.
When logging into Windows the first time, Winlogon.exe establishes an interactive logon by calling LsaLogonUser. It queries the authentication packages in HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Authentication Packages in order until it finds one that can authenticate the given credentials. Once an interactive logon has been established, you can create new processes using noninteractive logons under different credentials, and in this case, the LogonUser function is likely called. One of the parameters to this function is dwLogonProvider which has the following default (which is likely the one used):
LOGON32_PROVIDER_DEFAULT
Use the standard logon provider for the system.
The default security provider is negotiate, unless you pass NULL
for the domain name and the user name is not in UPN format.
In this case, the default provider is NTLM.
So, the package reported for the logon session the process is running under depends on how the logon session was created. (It isn't clear from your question exactly how you create the logon sessions you are testing... doing "Run As" in all cases? Logoff / Logon Windows for some cases?) It also depends on which package Winlogon was able to successfully authenticate with first for the interactive logon session. Ultimately, though, note that the authentication mechanisms all call down to some authentication package, and if Negotiate is used, Kerberos is preferred, though Negotiate is what is reported.
Here is an old but still relevant diagram which shows how all the authentication fits together in Windows:
Source
When i access my sing-on url(https://abcd.avcd.ac/adfs/ls/IdpInitiatedSignOn.aspx) from my code to establish connection with adfs, I get error as:
A WS-Trust endpoint that was configured could not be opened.
Additional Data
Address: https://win-3723jtvfe02.abcd.avcd.ac/adfs/services/trust/2005/windowstransport
Mode: WindowsTransport
Error:
MSIS0006: A Service Principal Name is not registered for the AD FS service account.
And I also get warning as:
The SSL certificate does not contain all UPN suffix values that exist in the enterprise.
Users with UPN suffix values not represented in the certificate will not be able to Workplace-Join their devices.
Please help me to figure out this issue.
For the SPN issue, you'll need to get that registered. There is a nice article about that on technet here: http://social.technet.microsoft.com/wiki/contents/articles/1427.ad-fs-2-0-how-to-configure-the-spn-serviceprincipalname-for-the-service-account.aspx
If you're not using the Workplace-Join feature of ADFS 2012 R2, then you don't have to worry about that other error. If you do want to address it, though, check out the docs here: https://technet.microsoft.com/en-us/library/dn614658.aspx