I have a non-AD KDC that is used by several database servers in the cloud for authentication. I have also configured my windows machines to authenticate against that same KDC. The goal is to run applications that access those database servers from the windows machine using single sign on.
That windows authentication against the KDC works. However when I login on the windows machine, the kerberos ticket is cached for an elevated session but not for a non-elevated one.
The applications and python scripts that access those database servers, do indeed work correctly with the cached kerberos tickets, provided they are run in elevated mode.
I would like to be able to use the kerberos ticket to run those apps non-elevated. Is it possible to configure the external KDC authentication mechanism in windows so that the ticket is cached for the non-elevated user?
Details:
So from a non-elevated command prompt:
E:\>klist sessions
Current LogonId is 0:0x303fd58
[0] Error calling API LsaGetLogonSessionData on LogonId (0:4ee3f0c): 0x5
[1] Session 3 0:0x31f6bfa MONET\Marcel Negotiate:NewCredentials
[2] Session 3 0:0x303fd58 MONET\Marcel Negotiate:Interactive
[3] Session 3 0:0x303fcf7 MONET\Marcel Kerberos:Interactive
But from an elevated prompt:
E:\>klist sessions
Current LogonId is 0:0x303fcf7
[0] Session 0 0:0x4ee3f0c NT AUTHORITY\SYSTEM Negotiate:NewCredentials
[1] Session 3 0:0x31f6bfa MONET\Marcel Negotiate:NewCredentials
[2] Session 3 0:0x303fd58 MONET\Marcel Negotiate:Interactive
[3] Session 3 0:0x303fcf7 MONET\Marcel Kerberos:Interactive
You will notice that for the elevated promp, the loginId is the Kerberos:Interactive session and indeed, from the non-elevated command prompt "klist" shows no tickets, while from the elevated command prompt "klist" shows all the kerberos tickets.
Related
I did extensive search before posting this Q.
We have a Kerb setup working fine for most users for our internal portal. For a few users we are getting the following error:
"Failed to create delegated GSSAPI token on behalf of
HTTP/ssologon.xxx.xxx.xx.com#XXX.XXX.XX.COM for
service#hostname.xxx.xxx.xx.com: Minor Status=-1765328230, Major
Status=851968, Message=Cannot find KDC for requested realm]"
I can test kerb setup fine from the Server side using Kinit using Keytab file etc.
Issue/Q is how do I test the same from the workstations/client PC which are exhibiting the above error.
I could use kinit or kinit principal-name but it prompts for a Password. But we have disabled Passwords authentication and use X509 certs/Access Card to login to our PCs/Domain.
So, how do we use Kinit or equiv. to test kerberos from a domain workstation
using CLI and Cert authentication.
I have seen the kinit -X option but it is not available on JDK1.7/1.8 in Win 7 it seems. Is pkinit (MIT Kerberos) an option but it seems more like used for web server to KDC authentication.
Thank you in advance and appreciate the community's time and effort.
---- Additional Info 1----
Btw, had the user purge all his tickets - klist purge and had her try accessing the SSO site (protected using IWA Kerb) and verified she is issued a kerb ticket
5 Client: xxjdoe # XXX.XX.XXX
Server: HTTP/ssologon.xxx.xxx.xx.xx # XXX.XXX.XX.XXX
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate
Start Time: 4/7/2017 13:54:59 (local)
End Time: 4/7/2017 23:54:48 (local)
Renew Time: 4/14/2017 13:54:48 (local)
Session Key Type: RSADSI RC4-HMAC(NT)
-------- End 1 ---------------
Get Cached Credentials in PowerShell from Windows 7 Credential Manager
This shows how to use a logged in user credentials in a powershell script. Can the same process be used in Task scheduler, so that the entered username and pword for the task, is then used by script above to pull the stored credentials.
Using Windows 2012 Task Scheduler which is supposed to support this
Trying to lean away from any storing passwords in encrypted files.
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
In my company I used to code on one of our domain controllers (DCs) with Windows Server 2012. However since I can not do it there anymore, I am now forced to code on my workstation using my normal user account instead of my domain administrator account.
The problem I encountered now was that when I run PowerShell as administrator I can use "Set-ExecutionPolicy unrestricted", but I don't have full access to our DFS filesystem since I am not the domain administrator with this account.
When I start PowerShell as the domain administrator I can not set the execution policy since I didn't run PowerShell as administrator.
How can I run PowerShell as administrator and domain administrator?
Scenario:
Normally, I would use remote desktop, log on to my server, launch the Powershell window as Administrator and perform the import-module and subsequent commands to get the information I'm looking for. When I log on using remote desktop, I don't log on as Administrator, but I do log on as a user that belongs to the Administrators group. (I don't have the Admin creds.)
Question:
I can easily create a session using New-PSSession. I can enter this session using Enter-PSSession. After I've entered the session, I import the module I need to use. After I import the module, I attempt to run a command from that module. I do get some output, but I also get "[Get-WmiObject], UnauthorizedAccessException". I do not get this error when I log on to the server with remote desktop and launch the powershell window as Administrator. Is there a way I can do this with a PSSession?
I met such a problem and it was due to the Forwarding of credentials in multihop environments.
Using New-PSSession you only have a network token on the second computer, you can’t directly connect to another computer.
The interactive token, I mean what you get when you sit down in front of a PC and log on (or using TS) is required to automatically connect to another computer, and to create an interactive token, the user’scredentials are needed.
To accomplish the interactive credential forwarding magic, PowerShell uses a mechanism called CredSSP (Credential Security Service Provider).
CredSSP need to be allowed on both side. You have to run these commands from an elevated PowerShell
session.
To allow CredSSP on the client side run :
Enable-WSManCredSSP -Role client -DelegateComputer computername
To allow CredSSP on the server side run :
Enable-WSManCredSSP -Role server
You've got a good explanation in Chapter 13. Remoting: configuring applications and services