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.
Related
After adding a user to the local Administrators group... even though the user is in the local group, they still don't have effective permissions as a desktop Administrator. They have to at least logoff/logon or reboot for the permissions to take effect. I was wondering if there's a way to do this via command-line in a seamless fashion.
This resource:
http://woshub.com/how-to-refresh-ad-groups-membership-without-user-logoff/
says, you can use:
klist -li 0:0x3e7 purge
However, after I ran that command, it didn't make any difference; I still had to logoff/logon or reboot for effective permissions to take place.
There are two things in play here:
What the local machine thinks your privileges are
What other machines think your privileges are when you connect to them
Purging the ticket cache with klist purge will remove your user ticket cache. This will affect (2), in that when you go try and communicate with another service you must first get a new TGT, which is the thing that actually contains your group membership information. This is why your membership information is cached for 'a while', i.e. because the TGT sticks around for a while, and when you ask for a ticket to another service, the Domain Controller literally just copies the contents of the TGT to the newly requested ticket, and that TGT can exist for a week or more.
Getting a new TGT will always return exactly what the DC thinks your membership is.
Affecting (1) is more complicated. Windows stores this information in what's called an NT Token, which is immutable for the lifetime of a logon session. The NT Token gets your group membership during logon. Windows asks the DC for that information, and copies it into the NT Token on receipt. This is why it appears as though your membership doesn't change, that is, because Windows hasn't gone off to get your new membership information and hasn't refreshed your NT Token (because it can't, because it's immutable).
As it happens though, a logon session is not forever, and actually only exists between session unlocks. Your membership information will get refreshed shortly after a lock/unlock once it communicates with DC.
0x3e7 is the ID of the SYSTEM account, not the user you are trying to manage. Issue just klist to get the ID of your currently logged on user. You can issue just:
klist purge
to delete the cached kerberos tickets of the currently logged on user. After that, just access a ressource where you need a kerberos ticket (e. g. a network share) and you will get new cached kerberos tickets automatically. If you don't have a particular network share, access the default share of your domain (just your domain name): \\mydomain.com
If time does not matter and you just do not want to login again, you can wait at most 10 hours. That's the default time span, after which a kerberos ticket will automatically be renewed.
Lenovo's system update program can be started without administrator right. When the service starts, it creates a temporary administrator account to perform the installation.
Why can a windows application have right to create an administrator-level account? How can I achieve it when I want to create a similar program?
It's related to TVSU. A design point of TVSU is that even limited users can install updates from Lenovo. And to accomplish this, the TVSU service creates a temporary admin account with a randomized username and password, then uses it to do the installations on behalf of the limited user. This is the only time the account is created. The account is not created when an admin user does updates, because the admin user already has the permissions needed to do installations.
The account is supposed to be deleted after the TVSU session finishes, but I'm aware of a case where this doesn't happen and the account stays around. However there isn't any security risk to this because both the account and password are random and not known by anything except the specific TVSU process that created them, and this process ended the last time TVSU was closed. You can safely ignore the account, delete the account, or else it should be deleted the next time TVSU is run.
I have DB2 11.1 installed on Windows 7. 'db2admin' user account was created to access this. I was able to create, select and perform all necessary actions. Everything was working properly, until one fine morning it started giving me this error while connecting to database.
SQL30082N Security processing failed with reason "19" ("USERID DISABLED or
RESTRICTED"). SQLSTATE=08001
I performed below things:
Reset the password
Verified if the user account is disabled on Windows.
Account is not disbaled
Verified if the account is part of appropriate groups and ensured it has all necessary privileges on Windows
User groups
Deleted the 'db2admin' account and created a new one.
None of them worked and am still unable to figure out the reason for this error.
Is the error misleading? If so, any suggestions to verify logs or anything to figure out the root cause?
Any help in resolving this is highly appreciated
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.
(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?