I deployed Hudson war in Websphere 8.5 and it was successfully deployed and first time I tried the Hudson url workied fine and in the Manage Hudson I confifured LDAP details and saved without validated. Now when I tried the Hudson url http://localhost:port/hudson it is always asking the User name and password tried a lot uninstall the Hudson application deleted the profile recreated and redeployed Hudson but still Hudson is asking the User name and password. I am unable to find the config directory in websphere and also I don't know how to by pass this. Please any body help on this where to change and to go Manage Hudson page without login.
Take a look at root configuration file config.xml stored in HUDSON_HOME directory. This config file contains configured user security and LDAP configuration.
Find line
<useSecurity>true</useSecurity>
and replace it with
<useSecurity>false</useSecurity>
HTH
Related
WAS is configured to use an Active Directory to authenticate, but the default admin account was left on the local file repository. When the AD connection is working we are able to login to the admin console using the default admin account, but when AD is down we are not able to use the default admin account to login. Any ideas as to why this is happening?
Any help would be greatly appreciated.
Check this link Unable to authenticate when a repository is down. You didnt write which version you are running, but by default if one of the federated repos is down you will not be able to log in.
You can use updateIdMgrRealm wsadmin command to set the –allowOperationIfReposDown parameter to true. This will allow you to log in with the user from working repository.
I've installed the LDAP Integration plugin in SonarQube(Version 5.4) and restarted the server.
I didn't make any changes to config file.
When I try to login, a credential prompt pops up, here I enter the same credentials I use to login to server. But even after this the sonarqube console asks me for a username and a password, this is the sonarqube username and password not the windows one's.
Do I need to make any changes for SonaQube to use windows credentials? or is it just ldap?
Please let me know if I'm missing something here.
Hello I just enabled Legacy mode authorization in Jenkins and it seems that it has now locked me out of all the administrative privileges.
I need to create an admin account so that I can continue with Jenkins configuration. I have direct access to the server and have tried running this line from command line:
java -jar jenkins.war --argumentsRealm.passwd.jenkins=swordfish --argumentsRealm.roles.jenkins=admin Jenkins starts but I am unable to access it from the web when starting from command line.
I've also tried starting Jenkins through services.msc, which is how I typically start it, and passing it the parameters --argumentsRealm.passwd.jenkins=swordfish --argumentsRealm.roles.jenkins=admin. Jenkins starts and I am able to access it through the web, but unable to log in with the username.
Any ideas how get admin access back?
I deleted the entries related to security and authentication in the config.xml, restarted, and I am able to access again. I was able to add myself as an admin using matrix based security. Still not sure how to do it with legacy tho.
Recently, I had the same problem. I would try to login to jenkins (hosted on glassfish), and would encounter the same thing. Basically getting a glassfish error that the application was not available. If I cleared all temporary internet files from browser, browse to jenkins home page, I would be presented with the Jenkins login, and when I provided the correct userID and password, WHAMMO! Back to application not available.... This too was using matrix-based administration.
To fix:
Locate the config.xml of the userID that is experiencing problems, under "users" directory.
Deleted the "apiToken" tag under "jenkins.security.ApiTokenProperty" tag.
Bounced glassfish and was able to login again.
I'm currently 'playing' with Plastic and their (brand new) TeamCity integration plugin.
The plugin blurb says "When installing Team City on Windows systems, it normally uses the SYSTEM user account. We recommend changing the user that executes the Team City application."
The thing is, I can't work out what kind of user I should substitute: I would like to be able to access Plastic (on the server) using AD, but wouldn't that mean that TeamCity would also have to run with a network user in order to be able to access Plastic?
An alternative (for me accessing Plastic) would be user/password - but I can't make the TeamCity service run with user/password.
Am I missing something obvious, or is the paint just too wet?
I'm also using PlasticSCM and the Team city plugin, this is my configuration:
For the server: configure your PlasticSCM server with LDAP authentification and select "Active Directory" as the server type.
For the client: configure your PlasticSCM client with LDAP authentification, use your credentials and try the "Test connection" button.
The client setup will generate a "client.conf" file at "C:\Users\your_user\AppData\Local\plastic". This file is used by PlasticSCM client to authenticate with the PlasticSCM server.
So, if your TeamCity service is running with the administrator account you have to place this file in your Administrator "...\AppData\Local\plastic" directory. If you change your TeamCity service to be run with your system account you don't need to do anything, the file is in the right place.
You have another option (if you are still running the TeamCity plugin as Admin), place the "client.conf" file where your "cm.exe" file is. Because the "cm.exe" is going to try to find this file first on its own location and then in the current user "AppData\Local\plastic" directory. This option is only valid if you are the only user working with PlasticSCM in the machine.
Hope it helps!
Scenario:
I set up successfully TFS2010 webdeploy task for solution. Everything worked fine until suddendly something went wrong in the deployment task.
Solution has 2 web projects..those are configured to deploy on build and publish it to the dev-server.
Does anybody have a knowledge what is wrong in build (information below)?
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
(3847): Web deployment task failed.
((4.8.2011 11:01:10) An error occurred when the request was processed on the remote computer.)
(4.8.2011 11:01:10) An error occurred when the request was processed on the remote computer. Unable to perform the operation. Please contact your server administrator to check authorization and delegation settings.
I can give more information if someone needs it.
I encountered the same issue when building via TFS. When I tried to manually import the website I got a more informative error: "not able to log on the user \WDeployConfigWriter".
Turns out that when you install web deploy it sets up two local accounts WDeployConfigWriter and WDeployAdmin. The passwords on these accounts are set to expire. So reset the passwords on the web server and set to "never expire". Then go to Management Service Delegation in IIS. Each of the presented rules has a UserName field. Where it is WDeployAdmin or WDeployConfigWriter right click and update the credentials to the new passwords.
A full explanation with screenshots can be found here: http://workinghardinit.wordpress.com/2011/07/18/wdeployconfigwriter-account-issues-trouble-shooting-web-deploy-2-0-with-lessons-learned/
All you have to do is re-run the script "AddDelegationRules.ps1" located in "C:\Program Files\IIS\Microsoft Web Deploy V3\Scripts\"
This is the script that is run when web deploy is first installed. It will re-create any missing delegations, re-set the passwords for both WebDeployAdmin and WebDeployConfigWriter, and add WebDeployAdmin back to the Administrators group.
You would still need to set the password on each account not to expire after re-running the script.
We had the same issue-- in our case we are only using MSDeploy (without TFS). Resetting the password for those 2 local accounts (WDeployConfigWriter and WDeployAdmin) solved the problem as their passwords had expired. We attempted to change the password policy to never expire, but only a local Administrator can do that.
run this command lusrmgr.msc
double click on user and
double click the account name, and tick "password never expires".
Done.
In my case it was a botched install of Web Deploy.
Uninstalling then re-installing Web Deploy fixed it for me -- Repairing didn't help.