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
Related
We have a PowerShell script to pull Power BI activity data (using Get-PowerBIActivityEvent), and I have been trying to automate it so that it can pull this data daily using an unattended account. The problem is the script must necessarily use the Connect-PowerBIServiceAccount cmdlet, which requires a credential. I don't want to have the passwords hard-coded anywhere (obviously) and ideally don't want to be passing it into the script as a plaintext parameter in case of memory leaks.
I've tried using SSIS as a scheduling mechanism since it allows for encrypted parameters in script tasks, but can't call the PS script with a SecureString parameter since the System.Management.Automation namespace isn't in the GAC (a commandline call wouldn't be possible).
I don't believe task scheduler would offer the functionality needed.
Does anyone know of any elegant ways to connect to the power BI service using encrypted credentials?
In the docs of Connect-PowerBIServiceAccount there are 2 options for unattended sign-in:
Using -Credential, where you pass AAD client ID as username and application secret key as password
Using -CertificateThumbprint and -ApplicationId
For both options you need to configure service pricipal and add proper permissions. I'm not going into details how to configure that, but most probably you'd need (at least) the following application permissions:
I'm not really sure what functionalities you need in the script, but in my experience, majority of the cases can be covered by scheduled task, so the explanation below will apply to that solution.
How you can secure the credentials?
There are variuos possible solutions, depending on your preferences. I'd consider certificate-based authentication as more secure (certificate is available only to current user/all users of the machine).
What's important in certificate-based authentication - make sure that the certificate is available for the account running the script (in many cases it's service account, not your user account).
How can I secure more?
If you want, you can store application ID as secure string (I don't have SSIS to test, so I'm not sure if there's any workaround to make it working in there) or use Export-CliXml. They use Windows Data Protection API (DPAPI), so the file can be decrypted only by the account which was used to encrypt.
To add one more level of security (I'm not even mentioning setting correct access rights to the files as it's obvious) you might put the file in the folder encrypted (you might already have a solution for disk encryption, so use it if you wish).
There are probably some solutions to secure the keys even better, but these ones should do the job. I'm using other Microsoft 365 modules with similar approach (Outlook, SharePoint PnP) and it works quite well.
NOTE: If you need to use user account, instead of service principal, make sure that you have MultiFactor Authentication disabled on that account for that specific application.
The relevant documentation to this (https://learn.microsoft.com/en-us/power-bi/developer/embedded/embed-service-principal) states that admin APIs (i.e. those served via Get-PowerBiActivityEvent) do not currently support service principals. This means it's not currently possible to use a registered app to run these cmdlets unattended.
There is a feature request open to provide this at the moment: https://ideas.powerbi.com/forums/265200-power-bi-ideas/suggestions/39641572-need-service-principle-support-for-admin-api
I've got a script that basically creates a user account on a number of systems, including Active Directory, and an IIS webserver that authenticates against that same Active Directory Domain.
Right now, if I just do my Invoke-WebRequest without specifying credentials, I get a 401 error, and if I use the credential switch, I have to specify or prompt for credentials. However, when it creates the Active Directory account, PowerShell is smart enough to uses the credentials of the user running the script to create the account, without having to specify or prompt for credentials.
Is it possible to do this same thing with Invoke-WebRequest?
As per TechNet for Invoke-WebRequest the -UseDefaultCredentials switch should do exactly what you are asking for:
Indicates that the cmdet uses the credentials of the current user to send the web request.
Hi I am new to SAP Business Object Central Management Console and trying to schedule a crystal report. For this I made an ODBC connection to a database(NCBODS) in the Server machine using windows authentication. I also gave same windows credentials in CMC as shown in below image. But It gives me an error saying
Error Message:
Error in File C:\Program Files\Business Objects\BusinessObjects Enterprise 11.5\Data\procSched\SDDVCTRTRCH11.reportjobserver\~tmp5448125TH7b9b16.rpt: Unable to connect: incorrect log on parameters. Details: [Database Vendor Code: 18456 ]
I have given the same windows credentials that I use to connect to the app server. Still I am getting "incorrect log on parameters"
But when I use a SQL Authenticated Login in the ODBC connection and also use the same SQL Login credentials in CMC it works fine.
So the problem here is when I use the windows credentials it throws error but works fine when SQL credentials are used. Is there any way I can use windows credentials in CMC?? I really appreciate if any one can help me on this
If you create an ODBC DSN with authentication set to trusted connection (Windows authentication), be aware that a different account will be used when creating the DSN and when using it in BusinessObjects:
When creating the connection: the DSN is created using the credentials you're logged on with (i.e. your Windows AD user account)
When running a report: the connection to the database is initiated through BusinessObjects, thus the account which BusinessObjects is running with, will be used to connect to the database.
In other words, you need to make sure that following requirements are met:
Your SIA (Server Intelligence Agent) which runs your CMS, Crystal Reports servers, etc must be configured to run with an Active Directory service account. By default, it runs with the Local System Account, which will not be able to log on to your database (as it's a local account, it's not even able to access network resources).
You need to grant the service account you used to configure the SIA in step 1 the necessary rights to your database.
Remarks:
If you're using AD SSO, you cannot schedule the report so that it uses the Active Directory credentials of a certain user (because BOBJ doesn't store these credentials, it only verifies them at logon).
If you're not using AD SSO, but are authenticating users to the BusinessObjects platform (InfoView) with manual AD authentication, you can set the option Synchronization of Credentials. This forces BOBJ to store the AD credentials when the user authenticates.
The credentials are stored in the user profile (Database Credentials).
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.
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