I am using a Perforce server but the only superuser account is lost due to the fact that the Perforce support guy (who use the superuser account) left the company and did not write down the superuser account details. My team is depending on the perforce server. What can I do now to regain administration control of it ? I do have administrative right of the Windows server that is hosting the perforce server.
A quick search on the internet reveals that Perforce gets asked about that a lot, and they did something about it: here is a link to their knowledge base article.
Here is the description of te problem from the article:
The super user is unable to access the Perforce database due to the following conditions:
When the only super user account listed in the protections table is accidentally deleted, but still remains in the protections table
The owner of the super user account forgets the super user account password
The idea behind the fix is to stop the server, move db.protect out of the way, bounce the server, change the password using any other account, then move db.protect back, and bounce the server again.
Related
We have a private repository on GitHub for our company's project. Initially i started off the repository, therefore current owner is me. But as the team grew we started to feel an urge to create a organization on GitHub which enables roles etc.
Current situation:
several distinct development machines are connected to the repository
by 'personal access tokens'. So their authentication is cached globally.
Live (production) server that is connected to the repository, with an 'SSH key' .
Test (development) server also connected to the repository. But it asks for authentication each time (username and password/PAT)
In this case, if a transfer the ownership of the repository from my account to company's organization: what I'll possibly break ? I've read that GitHub will redirect old URL to the repository will point to the new URL. But still, i think SSH key on the live server is likely to fail.
Can you please inform me about possible outcomes ? Thank you.
Edit 1: Results
Here is the results if anyone stumbles upon this post.
Old remote URL worked just fine, as stated in GitHub docs on transferring ownership. But we decided it's for the best to change the remote URL to new one, just in case.
Development machines with PAT worked just fine. No issue has been encountered.
We updated Live (production) server's origin remote URL right away so there won't be any funny business. SSH key had to be updated to comfort the new URL.
Test is still using old URL without any issue.
Generally, personal access tokens work based on the owner's access permissions, so if you continue to retain access to the repository, then those will continue to work. The same is true of SSH keys associated with the account. Similarly, other users who have their own PATs or SSH keys and continue to retain access will have those PATs or keys continue to work.
Ideally for most automated system purposes, you'll want to use SSH with deploy keys, because those are associated with the repository, so if someone leaves the company, things won't break. If you need to have individual users log into a server and pull, just have them forward their SSH agent.
If you need PATs for automated processes, such as for making API calls, you'll want to make a bot account and grant it access to the repository. That's much easier than trying to use individual people's PATs and again, it prevents employees who leave the company from breaking things when they lose access.
Whenever I try to open process definition in drools , Getting the Below Error
Invalid credentials to load data from remote server. Contact your system administrator.
I have given all permissions to role permission to user but still this error shows up.
While many details from your problem are not clear, here is the bottom line of this issue.
You are logging into the business-central with user 'nithish'. This user, will be used in the remote REST requests to your kie server instance. This means that user 'nithish' needs to exists on the kie-server side as well - otherwise kie-server will not recognise that user, thus authentication will fail. He needs to be created there with the same password and same roles as are present on the business-central side. I would advise at least
kie-server, rest-all,admin
roles.
The server you've installed your business central on has no access rights.
My company is currently migrating our on prem Exchange users to the hosted Exchange Online platform. Migrating users is easy but we have hit a snag when on boarding new users. Our environment has multiple RDS servers. In the past we would setup a users mailbox on one server and when they would log in to another server the settings would follow them. That does not seem to be the case with Exchange Online. We are having to logon to each RDS server and manually set them up each time they logon to a new one(only for new users). If the user had an old on prem Exchange account that we migrated to the cloud then those settings get over-written and their Exchange Online account comes over no problem. Just trying to figure out a way that will setup the new user EOL accounts when they logon to the new servers. We are using Roaming profiles too if that helps. Maybe some sort of powershell script that I can modify with the new users names when I am setting them up?
Sounds like the AutoDiscovery isn´t working correctly. Please check with the Microsoft Remote Connection analyzer if you see any errors (e.g. as explained in KB 2404385). Here is by the way a good starting point how that should work.
I'm kind of new with websphere. I was following an internal guide for setting up one of our company apps in websphere, but I changed one parameter in the admin console and after restarting the server, we cannot access with the administration console.
I checked the first option, when before the second one was, with user admin, and password admin also. Now, because It says "Server identity generated automatically" I have no idea what combination of user and password I need to enter in the administration console..
The administration console I'm referring to is the one located in server:port/ibm/console.
Thanks, this is really a serious problem for me, I would really appreciate any help I can get...
You should still be able to use whatever password you were using for admin user before making the change. Server user id is not used for restricting access to administrative console (see What is security property 'Server user identity' used for in Websphere Application Server?).
Nonetheless, since you can't access admin console at the moment (I'm assuming you mean that admin colsole login page shows up but you can't get admin user authenticated due to wrong password), first thing I'd suggest is turning of global security, so that you can use admin console to fix your settings and re-enable security. Once security is turned off, you won't be asked for a password during admin console login. Changing security settings in WebSphere Application Server with wsadmin technote gives step by step instructions.
If you are not sure about what password you have used for admin user, you must reset the password in the user repository you have configured (for example if you've configured LDAP, you must reset password at LDAP), before enabling security. If you are using a federated repository (this is default if you've not changed it), most probably admin user resides in file based repository, which is the first member of federated repository. In this case, you can just follow steps at How to reset the administrator's password in the file registry technote to reset your password. Otherwise you can try alternative documented at Updating your WAS administrator password (the link is from Lotus documentation but still is applicable).
Given that you have the command line 'xmlstarlet' in your terminal and,
WAS_HOME = Is your Websphere root location
PROFILENAME = IS your
profile's name
CELLNAME = Is your cell's name
Then,
xmlstarlet edit --update "/security:Security[#enabled='true']/#enabled" --value "false" $WAS_HOME/profiles/$PROFILENAME/config/cells/$CELLNAME/security.xml > /tmp/security.xml
cp /tmp/security.xml $WAS_HOME/profiles/$PROFILENAME/config/cells/$CELLNAME/security.xml
Summary: You are simply editing the correct security.xml file by changing the enabled="true" attribute to enabled="false" programmatically using xmlstarlet. Note that sed,awk,ed and other GNU tools lack the necessary ability to properly deal with the nested tree structure of XML.
On IBM DB2 v.9 windows, when someone connect to database by Server\Administrator user
DB2 database will automatically accept and grant all the permissions to this user?
But, in some case environment Administrator of server does not need to see every data in the database. So how to prevent Administrator use connect to database?
On 9.5 and older this would not be possible because the account under which your instance runs is SYSADM. Also Administrator can reset at least local account passwords and gain access to them, making changing the instance owner account useless.
However on 9.7 and onwards the instance owner will not have access to the data anymore. One option is to upgrade to 9.7. Furthermore you can set up an AD account for the connections your applications use. Local Administrator is not necessarily able to change into those credentials.
Still, the Administrator ultimately has access to the (usually unencrypted) database files. You can mostly improve the administrative aspect of security.
Umm... For many times I try to revoke with this command but when I connect to database by Administrator account DB2 will automatic grant permission to Administrator again.
I will try again for make sure.
By default, DB2 databases are created with CONNECT authority granted to public. If you want to restrict some users from connecting, you need to do
GRANT CONNECT ON DATABASE TO <user1>, <user2>, ...
Then revoke the CONNECT authority from PUBLIC
REVOKE CONNECT ON DATABASE FROM PUBLIC
I don't think it's possible under normal circumstances simply because Administrator is in the sysadm group.
Options I can think of (but haven't tried) include:
Setting the sysadm group to something else ("db2 update dbm cfg using sysadm_group blah"). Check the docs for caveats and gotchas when doing this, as I'm sure there are some.
Stop using OS authentication. Use a different security plugin (8.2 and higher only). This would move the authentication, and thus groups, to a new location (say an LDAP server). Then you just don't add Administrator to the new location, and especially don't add Administrator to the sysadm group again.
On Windows, the database manager configuration parameter SYSADM_GROUP controls who has SYSADMauthority at the instance level. When SYSADM_GROUP is blank (as is the default on Windows), then DB2 defaults to using the Administrators group on the local machine.
To fix this, you can create a new group in Windows and then modify the value of SYSADM_GROUP to use this new group. Make sure that the ID that the DB2 Service runs under belongs to this new group. After making this change, members of the Administrators group will no longer have SYSADM authority.
As Kevin Beck states, you may also want to look at restricting CONNECT authority on databases, too, because by default the CONNECT privilege is granted to PUBLIC.