I'm in a scenario (MDT) where I've got a single local user with a blank password, and the built-in Administrator account is set to auto-login via the HKLM...\AutoAdminLogon,etc. registry keys.
If I restart the machine during the MDT task sequence, the local user with blank password will login upon restart. I'd like to better understand this.
Am I dealing with a race condition in terms of which account gets logged in? I can find lots of info about the AutoAdminLogon registry keys, but can't find anything about how/why the blank password user auto-logins. I'd actually be happy to rely on the behavior I'm seeing if it is something "guaranteed" by how windows works.
I'm looking for any info on how blank password autologin works or thoughts on why it wins over AutoAdminLogon.
I learned a couple things.
First, AutoAdminLogon actually wins versus account with blank password. I was seeing evidence to the contrary because I had a step in my MDT task sequence that was inadvertently disabling the account set for AutoAdminLogon.
Second, I believe it is behavior like that being complained about here and here that covers the auto-login behavior of windows 10.
Unbeknownst to me, it was this auto-login last user behavior that was actually keeping my task sequence from failing even though I had unintentionally disabled the AutoAdminLogon account during the task sequence.
Related
I am running this in Windows 10
What is the difference between running a program in a user account with admin rights, versus running in a standard account but right clicking and running as admin - and by difference, I mean from the program's point of view.
I thought from the program's point of view, there would be no difference. But apparently that isn't exactly true.
See - I have this piece of hardware (The DLink Air Bridge for the Quest 2 Headset). It won't connect to the desktop app unless I run it in an account with admin rights. But here is the thing, if I run it in the same account (but now with only standard rights) but right click on the program and "Run as Admin" - it still won't connect. How can this be?
I am asking this here because the support for both Meta and Dlink is hopelessly, HILARIOUSLY inept.
Also - what is worse when it comes to security: Using an account for daily stuff with admin rights, or right clicking on particular programs that need it and always running as an admin. I assumed it was the latter - but I am an idiot when it comes to computer security.
When an administrator logs in, the full elevated token is stored in a system process and a more restricted token is generated from this and is used to start Explorer.exe at logon.
When this admin user elevates, UAC starts the new process with the full elevated token (often called "split token"). This causes some minor complications related to mapped network drives and HKCU COM objects but essentially the two tokens refer to the same user account and the same HKCU registry key.
On the other hand, when a non-admin UAC elevates they have to enter the credentials of an administrator and it is this administrator and their account/profile/HKCU that is tied to the token when the new process is started. Meaning, a process running as this administrator is present in the desktop session of the non-admin user. This means a different profile folder and different HKCU compared to other processes in the session.
According to Microsoft, UAC is not a security boundary. If you are really concerned about security then you need to log in as the administrator separately.
I have a machine which I want to find where my password hash is stored.
the set command returns details about the account and shows that it is connected to a domain however it doesn't show in net user. As well as this on advanced system settings -> User profiles the account shows as type: local and Status: local.
It seems to be a domain user however windows doesn't think it's on a domain.
Because of this searching for hashes has only brought up dead ends. They aren't in the SAM file and they aren't in SECURITY. I also tried password recovery software and the account simply didn't show.
I could see the correct hash through sekurlsa::LogonPasswords full - specifically serkurlsa::msv with mimikatz but now I would like to know where they are stored.
I know they are cached somewhere as I can login without internet, so I think I'm specifically looking for this file.
A brief search of the command suggests they are in the SAM database but I know they aren't.
Any assistance would be appreciated.
i've the following scenario:
In the company almost part of the computers works in domain. there is two admins with absolutely all permisions. Obviously, when a software is required in one of the computers one of the sysadmins must go to put his credentials and password.
So here starts the problem: with one of the admins everything works normally, but with the other user it's impossible. it says that the operation requires permissions elevation, and i insist that both users have exactly the same permissions.
Anyone have an idea what could be wrong?
thanks in advance
Let me see if I understand this. The first admin has no issues installing software, but the second admin does have issues (User Account Control Dialog box popping up). In what way have you determined they have the same permissions? Rather than answer that, just run through this checklist until you (or they) find the difference between their privileges and then correct it.
Compare the group memberships of their two accounts. One may be a Domain Admin, while the other might actually not be one, thus accounting for the UAC dialog box popping up.
If the above shows no differences, then compare a Resultant Set of Policy report between the both of them. This means when the first admin logs in, have him/her run this command: gpresult /H C:\Admin1.html
When the 2nd admin logs in, run a fresh report for him/her using gpresult /H C:\Admin2.html, then compare that to the first report, and act on any difference you see related to permissions:
(Skip to the bottom for the TLDR version.)
OK - so I have searched (really!) and all other UAC articles I have found seem to center on enabling, disabling, detecting or hiding UAC. My issue is not one of those, so here goes:
My user used to have the standard dual-token setup where I was in the Administrators group and the UAC's Consent UI would just ask me if I wanted to proceed. Now, we have separate administrative-level accounts that we need to use, and I have to authenticate with this new user. The problem I am having is that previously, starting an app as Administrator just elevated my current user, where now if I use the credentials of the new administrative user, whatever I am running runs AS that new user.
As an example, previously elevating CMD and typing whoami into the command prompt used to return my normal/current user, where it now returns the new administrative user.
This has serious negative consequences - since this is a new user, and an Administrative-level one, if any files are created using this new user, my normal user cannot write to or delete them unless I manually adjust permissions and ownership. If I use my development environment under the new account (e.g. I need to debug a service or work with a driver) and rebuild something, I end up with a bunch of files that I cannot manipulate unless I am an administrator. Likewise if I add a file while running as this new account - my SCM tool will not be able to update that file later unless it also runs under this new administrative account.
Also, Since a profile is associated with this user, things run under a completely different environment (different %USERNAME%, %USERPROFILE%, %LOCALAPPDATA%, etc.)
Installing an application will also work incorrectly if it is installed just for the current user (e.g. the "Just Me" option), instead of for all users. Things that are licensed to/in my normal user account also fail to function if run under the new account, because things are running as that new user.
The ripple effects of this change are getting larger and larger the more I work with it. So...
[TLDR] Is there a way to get temporary elevation of the current user without that user having the normal dual-token setup you get from being in the Administrative group? Or are you stuck with the impersonation behavior?
The DC is set up to lock out after three failures however this particular member that has some different applications is getting locked out after one failure. Any ideas what could be causing this to happen?
This mostly happens when the user has logged on to another device with their credentials then changed their password. Now the other device/service is trying to log on/run with the old cached credentials. This has happened to me a few times before because I have tasks running on multiple servers under my credentials and after changing my password (90 days) I forgot to change them on the other machines. Try having the user log out or shut off all devices they have used then reset their credentials. That worked for me. Microsoft also has tools to figure out where these credentials are being used.