I implemented my own custom Windows credential provider following the Windows SDK example which should let a remote application connect to a server and perform logon automatically.
The problem is: the SetUsageScenario event is not called until a user presses the SAS combination (Ctrl+Alt+Del), therefore my credential provider isn't able to automatically perform the login until that happens.
How does RDP do the login automatically without me pressing Ctrl+Alt+Del and logging in automatically? How do I do the same with my custom credential provider?
SAS can be skipped for Console session only if You turn it off manually in the registry/policies.
RDP session always skip SAS and direct You to enter credentials.
Moreover modern RDP client asks for credentials prior to establishing connection to remote server. It serialize your credentials and send them to remote server. On server authentication is done using this serialized data.
Related
Is there any way to keep client third party service password secured from others being able to access server machine?
Password is used to send messages between two system, from A->B. There are 3 actors:
client - owner of the infrastructure and user of system A and B
provider A - author of system A which have ablitity to RDP into client server and administrate it to keep system A working
service B - service providing access to system B, secured with password known to client which provider A shouldn't directly know
Every solution based on encryption and storing password in configuration/database is not an option because provider A will always have access to decrypting algorithm and mangled password.
Best solution right know is based on keeping password in server Windows Credential Manager. Provider A can use it inside message sender process by its code but password itself is not directly visible in server. It always can be retrived by provider A but it is a bit safer.
Is it possible using Custom Credential Provider to make windows logon without real password of local user?
I'm already able to install/register sample code from Microsoft, and even able to debug it.
My expectation from this mechanism: User inputs some password and my implementation performs some comparison against local database of my password (stored as sqlite database).
Reality: local user password MUST be passed to LSA subsystem within
ICredentialProviderCredential::GetSerialization(...)
Frankly speaking I'm trying to use some sort of -one-time-coupon codes as passwords, to login to a kiosk-like workstation.
This is the main reason for developing custom credential provider.
Your provider must return to the Logon UI or Cred UI the authentication information. It can be a login/password pair or a certificate based authentication.
Inside of your database you can store a real user's password and return it after checking your own OTP.
We call DirectoryEntry.Invoke("SetPassword",newpwd) to change the password of a local user, but the new password is not being used immediately when doing Windows Authentication to a remote SQL server. It does get used after a reboot, but that's not really an option for me here. How can I make it take effect without rebooting? I need currently running processes on the client to begin using the new password immediately.
The environment is two Windows 7 Embedded systems, call them 'server' and 'client', and there is no domain, but they are both in the same workgroup. We use the same username on both systems. There are multiple servers out there with different passwords (computed based on various things). When we need to switch to use a different server, we change the password locally. The change itself is successful, but SQL accesses from client to server fail with
SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure.
and
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
But as soon as client reboots it can access server's database successfully.
SQL Express 2008 on both systems, configured to use only Windows Authentication.
Wireshark shows me the SMB2 NTLMSSP_AUTH packet with what looks like the usual info although I don't know how to decode the security blob. Otherwise it matches the packet from a successful session. In the failure case this packet is followed by an SMB2 response with STATUS_LOGON_FAILURE and a missing security blob. I can only think that the client presents some kind of hash of the password in that security blob and the server is finding that it doesn't match its own password hash - or something like that.
Changing the environment ('Use Active Directory', 'Use Kerberos', etc.) is unfortunately not an option for me here. Also, these are consumer touch-screen kiosks, where no human ever knows the password, and wouldn't have a keyboard to enter it anyway.
ADD: FYI, The changing of the password is done thus:
DirectoryEntry directoryEntry = new DirectoryEntry(string.Format("WinNT://localhost/{0}", username));
directoryEntry.Invoke("SetPassword", newPassword);
ADD: Made that parameter new object[] {newPassword}, and called .CommitChanges(), because those look like correct things to do. No change in behavior.
I developed an Intranet application which needs to realize a "git push" from a local repository (on the disk of the web server) to a remote repository.
I launch the git process from the web server, it runs under the IIS pool identity which is a domain account member of the administrators group of the web server machine.
Git needs the user credentials to perform the push action. I integrated a custom version of git-credential-winstore. This program uses the Windows Credential Manager to store generic credentials for a web site. But when the call to the credential's write occurs, I get the error :
Failed to write credential: A specified logon session does not exist. It may already have been terminated
I checked the policy "Network access: Do not allow storage of passwords and credentials for network authentication", it is disabled.
What goes wrong here ?
Pool account needs to gain access to its user profile.
So we need to connect one time to a Windows Session to create user profile (I think it's necessary). Next in the Advanced Settings of the dedicated Application Pool, set "Load User Profile" = true.
Note about credentials : Windows credential target must be changed to manage different users in the same Windows vault. I change "git:https://remote-host" by "git_USERID:https://remote-host".
I set this property to enabled and it works now, maybe it will work for you also:
Since version 5.50 the Bitvise SSH Server allows connected client to authenticate to Windows user account without providing this user's Windows password. See here: https://www.bitvise.com/ssh-server-version-history
I've checked it myself - it does indeed.
My question is of pure curiosity: what kind of sorcery is this? Is there any WinAPI that allows such thing or is this some kind of clever hack? I always thought it is impossible to impersonate as other user without a password (as even when configuring Windows service or scheduled task to "run as user" it is neccessary to provide one).
IIRC, the SSH server in Cygwin does the same thing.
If you have the appropriate privileges you can create an access token with ZwCreateToken, no password required. Such a token has some limitations. For example, you can't access network resources without a password and some encrypted material isn't accessible.
There's an explanation and some sample code here.
Since version 5.50, Bitvise SSH Server comes with a Windows authentication package. An authentication package can enhance the Windows logon process in custom ways. When the SSH server needs to log you in, but does not have a password (e.g. because you logged in with a public key), it calls the authentication package to construct a logon token which closely resembles the logon token that would have been created by Windows. As arx has noted, a session created this way does not contain your authentication credentials, so side effects are that you can't access things like network resources and EFS.