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
Related
I am running a windows 2016 server, we are running IIs 10 on it and i need to be able to assert if there is an AppPool setup before i deploy a website. If it doesn't exist i need setup the AppPool with a specific user and password.
All of this is done using a release agent through Azure Devops.
The agent is running as a NON-ADMIN, and i all accounts involved are running as NON-ADMIN. I have no intention at all to run any admin accounts, for security reasons i want to give least privildges to all accounts involved.
when i try to set up a AppPool using appcmd.exe i get the error msg:
KeySet does not exist.
When running everything as admin it works (and i have absolutely no intention in running any of this as admin).
What i have tried:
i have added the non-admin account to the IIS_IUSRS group.
Made sure that the user has read permissions to the file: 76944fb33636aeddb9590521c2e8815a_GUID in the %ALLUSERSPROFILE%\Microsoft\Crypto\RSA\MachineKeys folder.
i have tried everything here: Error when you change the identity of an application pool by using IIS Manager from a remote computer
anyone that actually knows the cause of this problem?
UPDATE:
Microsoft clearly recommends that agents should be run using service accounts, which i am doing and i have no interest in giving build agents administrative rights to 1000s of servers when they clearly don't need that kind of powers actually. I want to restrict their powers to only be allowed to do what they need to do. I can't believe that giving everything admin is apparently the norm.
After a lot of googling, and i mean A LOT. I managed to solve this. And let me say, that it baffles me that "least privileged accounts" is not common practice in the Microsoft and windows world.
I found this excellent post by InfoSecMike locking down azure devops pipelines.
And we both have the exact same requirements and opinions on this topic.
You CLEARLY don't need admin rights to update IIs configurations (because that would be insane, right!?). The IIs configuration API does not care what rights you have, what you do need is access to certain files. But this is not documented. Microsoft themselves, just for simplicity, tells you that you need to be admin, and buries all the details really deep in documentation when this should be best practice. Also what amazes me is that no one questions it.
What you need is the following:
full access to C:\Windows\System32\inetsrv\Config
full acccess to C:\inetpub
read access to three keys in C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\
6de9cb26d2b98c01ec4e9e8b34824aa2_GUID (iisConfigurationKey)
d6d986f09a1ee04e24c949879fdb506c_GUID (NetFrameworkConfigurationKey)
76944fb33636aeddb9590521c2e8815a_GUID (iisWasKey)
The 2 first bullet points can be obtained if you make sure your service account is a member of the group IIS_IUSRS.
This group will not give you access to the keys. You need to manually give read permissions to these 3 keys to the agent user.
If you don't give access to these keys you will get the obscure error message
Keyset does not exist ( exception from HRESULT : 0x8009000D)
Which is an incorrect error if you ask me as it should be an IllegalAccessException with proper reason telling you that you don't have access to read the key because the keys are there, they do exist (nice code microsoft, maybe you should open source this so we can fix).
I'll leave with this quote from infosecmike.
The goal was to lock down the permissions of the Azure Pipeline Agent {...}. I started Googling, pretty sure I would find a way to achieve this goal. I didn’t. It’s surprising to not find an answer about this. It seems like the principle of least privilege does not apply anymore in a devops world.
This is why i prefer Linux over Windows. This is a simple task there.
I have 40 users in my sonarqube instance.
After updating to Sonarqube 6.5 in Administration/Security/Users there is only Administrator.
Sonarqube connected to PostgreSQL database and table users contains all 40 users. Also they can login. Creating missing users fails with message: An active user with login 'XXXX' already exists.
I tried REINDEX DATABASE sonarqube; with no result.
How can I solve this problem?
The list of users is by default not shown completely in newer versions of SonarQube. Start typing a user's name or email in the filter input box to find the users you are looking for.
While a list of 40 users would be easy to display, some instances of SonarQube have thousands of users. The new behaviour of the user list improves the user experience on such systems.
Side note: If an unexpected error occurred during startup you indeed might have to reindex the database once. To do this stop SonarQube, make a backup of everything, remove the data/es directory and start SonarQube again.
I am getting error "CWWIM4538E Multiple principals were found" at server startup. I know the cause as the local WAS admin account has its duplicate in LDAP repository. I simply wants to remove the local WAS user gracefully offline as server won't come up. I tried playing around with changing the user id info in fileregistry.xml and corresponding change in security.xml but to no avail.
Seems that you've added LDAP into "federated repositories" and forgot to remove "internalFileRepository" which contains wasadmin as well. You can do it in profiles/dmgr/config/cells/myCell/wim/config/wimconfig.xml, where you just remove it from the realm.
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.
I am trying to deploy a SQLCLR library to SQL Server 2008 R2. In visual studio I have set up the data connection and it works correctly (I can run queries), but when I try to deploy I get the message "Error: Could not obtain information about Windows NT group / user , error code 0x3a."
This is strange because I have set up the data connection to use SQL server authentication on a different user name.
I receive the same error when I run CREATE ASSEMBLY while logged in to the SQL management studio with the different user name.
To add to the mystery, when I deploy using permission set SAFE everything is fine. However my assembly requires EXTERNAL ACCESS.
What could be the problem with deploying my assembly?
This issue wasted so much time I feel compelled to share the solution so that nobody else falls into the same trap.
Issue was resolved by setting the SQL Server Active Directory Helper service to run on Manual, then rebooting the server.
This issue arose in a different environment for me:
Windows 10 box;
The user Windows complained about was an AZUREAD user;
On my Win10 box there was no SQL Server Active Directory
Helper service, so I couldn't try the original solution posted by
ose.
I was able to work round the issue by removing the AZUREAD user as a SQL Server user while I added the assembly.
In my case that user was not essential to have as a SQL Server user, but I dare say it would be possible to re-add the user back later should this be required.