I'm investigating a failure in my Windows 10 Credential Provider. It calls out to LookupAccountName in order to get the SID of the user that is attempting to log in. Its per-user configuration uses the account SID as the key.
The failure scenario is as follows:
There is a mixture of local and domain accounts on a domain joined computer.
The computer is in an offline or otherwise disconnected state and cannot contact the domain controller.
The domain user has logged in to this computer in the past and its credential is cached.
The call to LookupAccountName fails with ERROR_TRUSTED_RELATIONSHIP_FAILURE (0x6FD)
Here's where things are interesting:
I can log in with a local account and then "Run As" the domain user. Then subsequent calls to LookupAccountName (even when run in the context of the local user) succeeds in looking up the SID of the domain user. It will continue to work until the computer is rebooted.
I've tried calling LookupAccountName as well as LsaLookupNames2. Both exhibit the same behavior. (I assume LookupAccountName is built off of LsaLookupNames2).
It doesn't look like the NetUser* APIs will help me, as I believe they are intended for local accounts.
Is there a way to lookup the account SID for an offline domain credential? Without requiring them to log in first?
Why does using "Run As" cause these APIs to suddenly work?
Related
I am using powershell to get audit fail events 4625 and 4771 from the Domain Controllers. Most of these are 0x18 Status. Now i understand the events with usernames (don't end in a $) as having bad passwords from a machine. Most of the google examples show 4771's from users.
What i want to understand, is what it means when it is coming from a machine?
i.e. surely it is an account on the machine which has an issue, how does a machine have a bad password? And if it can, how does one find out what the issue is ?
Active Directory is an identity management system, and so anything that authenticates with Active Directory needs an "identity" of some sort. Since computers themselves can be joined to a domain and must authenticate against it (with a username and password via Kerberos the same as a regular user logon), they have a username. The AD machine account username is the computer's DNS hostname followed by a dollar sign, for example: Desktop-AB123$
Since every computer in the domain must authenticate against the domain with a username and password, it is possible for that authentication to fail. And it can fail for all of the same reasons that a regular user logon can fail: unrecognized or misspelled username, incorrect password, wrong domain or UPN suffix, or any number of authentication errors.
Event ID 4771 indicates a Kerberos preauthentication error and status 0x18 (usually) indicates a bad password. Source.
Machine accounts renegotiate their password automatically with the Domain Controller when they connect to the domain. If a domain-joined workstation is unable to communicate with a domain controller long enough for the password to expire, it will not be able to log in and you will get a failed logon for that computer's machine name. The computer will need to be rejoined to the domain (or have its password reset using Reset-ComputerMachinePassword and a domain admin credential). The same is also true if a domain controller is unable to communicate with the PDC Emulator. This will be the most common type of error that will lead to failed machine account logins. The second most common will probably be due to computers being renamed while unable to contact a DC, changing the computer's logon username without updating AD.
Beyond password expiration or computer renames, you have to start looking deeper for root causes. These are likely going to be Kerberos negotiation errors caused by services attempting to authenticate in order to perform certain actions. Note that the authentication error does not necessarily occur at service start and may occur when the service is accessed or triggered by another application. I recommend reviewing my question & answer in ServerFault regarding one such example where a server's DNS name didn't match its NETBIOS name, which caused Kerberos authentication to fail and fall back to NTLM.
As that ServerFault question illustrates, tracking down the root cause of a failed machine logon, once you've ruled out username and password errors, can be extremely difficult. Your first step should probably be to enable Netlogon debug logging and then searching the netlogon log file for your failure events. You can also search the SYSTEM event log for any events related to services failing to start. After those two starting points you're basically on your own and will need to develop some advanced troubleshooting and investigation skills to track down the root cause.
One final note, your question is not exactly related to programming or software development, so SuperUser or ServerFault might be a better place for questions such as this in the future. ServerFault is geared towards professional sys admins working in production environments while SuperUser is more geared towards hobbyists, enthusiasts, home servers, and DIYers.
I was installing the filebeat application and I noticed that I needed to run powershell as administrator in order to install them. When I checked the service using wmic service get name,startname,status it showed Local System. I'm wondering what this account is as this is neither the user account or the administrator account. Will this always be the case when I install services as administrator? What is the difference if I install it as a normal user and as administrator?
In any case, I've set this service to start automatically when windows start. Would this service start only when the user I used to install it logs in or will it start regardless of which user logs in?
OK, let's unpack that one by one, in no particular order:
Only a user with administrator rights can install a service.
Services that are configured to start automatically are started as soon as Windows is up and running; Windows does not wait until somebody logs in. It makes no difference to the service who the logged-on user is, or whether anybody is logged in at all, unless the service application itself has been explicitly programmed to check.
The program that installs the service decides what account the service uses to run. Windows doesn't care what user account was used to install the service, it doesn't even keep track.
If the program that installs the service wants it to use an ordinary user account, it must know the password for that account. There are various special accounts that a service can run in, these accounts do not require a password. One of these special accounts is Local System.
Local System is the highest-privilege service account in Windows; it has all the same rights as an administrator, and can do things an administrator can't. Local System is also the account that the user-mode part of Windows itself runs in, roughly equivalent to the UNIX root account except that it doesn't have a password.
Additional notes, for completeness:
One alternative to Local System is for the service to run as Local Service or as Network Service, which are non-administrative service accounts. The only difference between the two is that if the computer is joined to an Active Directory domain, the Network Service account has network access to other machines in the domain and the Local Service account does not.
It is also possible to configure a service to run in a special service account that is unique to that particular service. This is mostly useful if you want the service to have access to a particular file or folder, but do not want to give it administrator rights.
Nitpickers corner:
It is I believe technically possible to reconfigure Windows to allow non-administrators to install services, but this is not supported and would be a Very Bad Idea. If you did, though, it would still make no difference who installed the service. Windows doesn't record this information.
I need to call WNetGetConnection to get the UNC path and it works good when application run as standard user but it returns 1201(ERROR_CONNECTION_UNAVAIL) error code when application run as admin. According to the documentation its working as expected.
If the network connection was made using the Microsoft LAN Manager
network, and the calling application is running in a different logon
session than the application that made the connection, a call to the
WNetGetConnection function for the associated local device will fail.
The function fails with ERROR_NOT_CONNECTED or
ERROR_CONNECTION_UNAVAIL. This is because a connection made using
Microsoft LAN Manager is visible only to applications running in the
same logon session as the application that made the connection. (To
prevent the call to WNetGetConnection from failing it is not
sufficient for the application to be running in the user account that
created the connection.)
that means its not possible at all to get the UNC path from the app running as admin ? Is there some other way ?
This is by design. Network shares created by a non-elevated account are not visible under elevation, and vice versa.
See this question on Super User for discussion of the issue. There is apparently a registry setting that enables mapped drives to be shared between elevated and non-elevated accounts but I've never tried it myself.
Network connections cannot normally be shared across different Windows login sessions. This is regardless of admin account / elevation level. Each Windows login or impersonation session needs to create its own network connections.
I'm writing a Windows device driver for a custom USB device, but am having trouble opening the device from my user program (using CreateFile) when the user program is run as a domain user. If I run as a local user, or as an administrator (or 'Run As' administrator) I can open the driver fine, but as a domain user GetLastError returns 5 (access denied).
I originally had this problem with local users too, and found I had to add the following SDDL entry to the .inf file, which solved the problem for local users:
HKR,,Security,,"D:P(A;;GA;;;SY)(A;;GA;;;BA)(A;;GRGW;;;BU)
From this reference:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff563667(v=vs.85).aspx
When I discovered that domain users did not have access I thought that simply adding them to this SDDL entry would give them access, but it doesn't seem to work: I still get access denied. I've even tried extreme solutions such as giving all users (everyone (WD), unauthenticated users etc.) full access, but this doesn't work either, which makes me think the problem lies elsewhere; i.e. something else is denying domain users access which takes precedent over the permit in the SDDL entry in the driver inf.
So my question is, what am I missing that is required to give domain users (or all users) access to connect to the driver? Or are there any other solutions to this problem (such as connecting to the driver as a service and then accessing this service from the user program)?
HKR,,Security,,"D:P(A;;GA;;;WD)"
set everyone can access, try it!
My question is pretty much summed up in the subject.The context is a problem we are facing with the account getting locked our fairly often.
My setup uses this as the service acccount for clearcase application.
There is another account by the same name (but in a different domain - a trusted domain) that runs a monitoring sofftware under this account. For eg., my setup uses the accoundt DOMAINA/clearcase_albd, while this other trusted domain runs a batch file under TRUSTEDDOMAIN/clearcase_albd.
We are suspecting this account to be causing the locking out of our service account (but at this point have not yet figured out why!)
Have pored over event logs endlessly, to no avail and have now decided to start fresh from ground zero.Am following a thread of thought and the first thing I need confirmation on is this:
Should I be seeing DOMAINA/clearcase_albd account when i run clearlicense at all?
If not, then why would another account by SAME name but from a different domain lock out my domain account?
Would greatly appreciate any help in this regard,
Thanks in advance
According to the IBM ClearCase Manual, the Rational® ClearCase® albd_server program runs with the identity of a special user account known as the Rational ClearCase server process user.
This user is a member of the Rational ClearCase administrators group, which grants privileged user status.
That account should not directly uses a license, as it is related to the albd (Atria Location Broker) process which will execute operation on behalf other users.
When a client program needs access to a service (a VOB or view server, for example) on a Rational ClearCase server host, it uses a remote procedure call (RPC) to send a request to the albd_server process on that host.
The albd_server starts the requested service if it is not already started, and provides the service’s port number to the client. Thereafter, the client communicates directly with the service.
IBM does suggest two albd accounts, for central VOB/view servers and end-user workstations. This is primarily done to prevent albd account issues (account lockouts, etc) on the albd account from impacting the VOB servers themselves.
BUT: those accounts should be on the same domain.
Note: by typing
creds clearcase_albd
You will see its SID for the current Windows domain.
You will then be able to check if that SID pops up in the clearlicense command output.