How to migrate a technical user to a LDAP one? - ldap

I have nearly all my users setup as local (technical as SonarQube doc calls them) users and just installed & configured the LDAP plugin 2.2 to connect to my Active Directory.
The connection works fine: if an user unknown to SonarQube but existing in LDAP tries to log in, its user is automatically created.
I'd like to convert my existing SonarQube users (not linked to LDAP) to LDAP users so that their password and group memberships are automatically updated, but could not find how to do this in the documentation.
I found this answer how to change a local user to ldap, but it didn't work: when I try to login with LDAP credentials and the same login, I get an "Authentication failed.".
Some background:
At some point in time (i.e. some years and SonarQube versions ago), I had configured the LDAP plugin and everything worked as expected. This configuration somehow disappeared during an update, and the LDAP users were all converted to technical users (or so I assume).
I could not find a way to delete a user (as suggested in the SO post I linked above), only deactivate. Semantics, but it may have some importance.
I'm running SonarQube 5.6.1.
Edit:
I updated to the latest LTS version 5.6.6.
With trace logs activated:
When I try to log in with a deactivated local user (hoping that this would find it in LDAP):
TRACE web[sql] time=0ms | sql=SELECT count(`users`.id) AS count_id FROM `users` WHERE (login='tguerin' and user_local=1)
TRACE web[sql] time=1ms | sql=SELECT * FROM `users` WHERE (login='tguerin' AND active=1) LIMIT 1
TRACE web[sql] time=0ms | sql=SELECT * FROM `properties` WHERE (((`properties`.`resource_id` IS NULL AND `properties`.`user_id` IS NULL)) AND (`properties`.`prop_key` = 'sonar.allowUsersToSignUp')) LIMIT 1
DEBUG web[http] POST /sessions/login | time=224ms
Nothing more in the logs: no call to LDAP
When I try to log in with a user that doesn't exist (neither as local nor in LDAP):
TRACE web[sql] time=3ms | sql=SELECT count(`users`.id) AS count_id FROM `users` WHERE (login='notLocal' and user_local=1)
DEBUG web[o.s.p.l.LdapUsersProvider] Requesting details for user notLocal
DEBUG web[o.s.p.l.LdapSearch] Search: LdapSearch{baseDn=...), parameters=[notLocal], attributes=[mail, cn]}
DEBUG web[o.s.p.l.LdapContextFactory] Initializing LDAP context {java.naming.provider.url=ldap://x.x.x.x:389, java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.security.principal=..., com.sun.jndi.ldap.connect.pool=true, java.naming.security.authentication=simple, java.naming.referral=follow}
DEBUG web[o.s.p.l.LdapUsersProvider] User notLocal not found in <default>
TRACE web[sql] time=0ms | sql=SELECT * FROM `properties` WHERE (((`properties`.`resource_id` IS NULL AND `properties`.`user_id` IS NULL)) AND (`properties`.`prop_key` = 'sonar.allowUsersToSignUp')) LIMIT 1
DEBUG web[http] POST /sessions/login | time=66ms
The database is checked, then LDAP, as expected.
Edit2: to rule out a problem with a particular config/plugin on my server, I fired up a Docker Sonarqube 5.6.6 container, added a local user, added LDAP plugin (restarted, LDAP config ok), deactivated the user, tried to log in: same behaviour (i.e. the LDAP server is not queried)

As nothing seemed to work, I decided to inspect the database.
Changing field user_local in table users from 0 to 1 did the trick. I can't imagine this being recommended by SonarQube, but as of now, I did not find any side effects.

Related

msdeploy error ERROR_USER_UNAUTHORIZED: Web deployment task failed

Web deployment task failed. Error ERROR_USER_UNAUTHORIZED
We are using Tfs Build Automation and msdeploy for publishing an web application on remote machine.
On "Visual Studio Build" step we set this parameters on "MSBuild Arguments":
/p:DeployOnBuild=true;PublishProfile=myProfile;AllowUntrustedCertificate=true;UserName=$(UserName);Password=$(Password)
After quing the build we get this error:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\Microsoft.Web.Publishing.targets(4276,5): Error ERROR_USER_UNAUTHORIZED: Web deployment task failed. (Connected to the remote computer ("MySERVER") using the Web Management Service, but could not authorize. Make sure that you are using the correct user name and password, that the site you are connecting to exists, and that the credentials represent a user who has permissions to access the site. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_USER_UNAUTHORIZED.)
I am sure that username and password is correct, and the user isAdministrator on the server (MySERVER).
I checked the Management Service log on IIS and found something important:
the build agent's username(tfsadmin) sent for deploy on IIS instead of the user/pass that I set in build variables.
Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
2018-01-03 09:29:02 MYSERVERIP HEAD /msdeploy.axd site=MySiteName 8172 - MyBuildServerIP - - 401 2 5 1322
2018-01-03 09:29:02 MYSERVERIP HEAD /msdeploy.axd site=MySiteName 8172 tfsadmin MyBuildServerIP - - 401 1 1326 86
Update 1:
I add more information, as you see below in build log, in msBuildArgs the password is empty (instead of ********)!
WebDeploy Version : 3.6
TFS Version : 2015.1
Target Machine (MySERVER) : Windows 2012 R2
IIS Version : 8.5
The "tfsadmin" user has local administrator of target server (MyServer) and IIS Manager Permission on the target IIS Site.
Build log :
2018-01-06T06:37:19.9298797Z Starting task: Build solution $/MyProject/MySolution.sln
2018-01-06T06:37:20.0529203Z Executing the powershell script: D:\Agents\Agent-01\tasks\VSBuild\1.0.16\VSBuild.ps1
2018-01-06T06:37:20.3760645Z ##[debug]Entering script VSBuild.ps1
2018-01-06T06:37:20.3790648Z ##[debug]vsLocation =
2018-01-06T06:37:20.3800653Z ##[debug]vsVersion = 14.0
2018-01-06T06:37:20.3810663Z ##[debug]msBuildLocation =
2018-01-06T06:37:20.3820668Z ##[debug]msBuildVersion =
2018-01-06T06:37:20.3830692Z ##[debug]msBuildArchitecture = x64
2018-01-06T06:37:20.3840679Z ##[debug]msBuildArgs = /p:DeployOnBuild=true;PublishProfile=myProfile;AllowUntrustedCertificate=true;UserName=tfsadmin;Password=;Pass2=********
2018-01-06T06:37:20.3840679Z ##[debug]solution = D:\Agents\Agent-01\_work\2\s\MyProject\MySolution.sln
2018-01-06T06:37:20.3860721Z ##[debug]platform =
2018-01-06T06:37:20.3870700Z ##[debug]configuration =
2018-01-06T06:37:20.3880727Z ##[debug]clean = true
2018-01-06T06:37:20.3890697Z ##[debug]restoreNugetPackages = true
2018-01-06T06:37:20.3890697Z ##[debug]logProjectEvents = true
2018-01-06T06:37:20.4010877Z ##[debug]Loading module from path 'D:\Agents\Agent-01\agent\worker\Modules\Microsoft.TeamFoundation.DistributedTask.Task.Internal\Microsoft.TeamFoundation.DistributedTask.Task.Internal.dll'.
...
Can anybody help me ?
You are correct that the wrong username and password were ultimately used to authenticate the request. Running the command net helpmsg 1326 (1326 is the sc-win32-status value from the log entry you provided) yields "The user name or password is incorrect."
Also interesting is the request/response logged before that. The substatus value 2 for a 401 means "Access is denied due to server configuration favoring an alternate authentication method." according to TechNet. And net helpmsg 1322 yields "This operation is disallowed as it could result in an administration account being disabled, deleted or unable to logon."
Review (or re-review) the instructions at https://learn.microsoft.com/en-us/iis/publish/using-web-deploy/configure-the-web-deployment-handler
If your deployment is still not working, take a look at Microsoft's Troubleshooting Common Problems with Web Deploy.
Deploy from VS with the command line will use the user name and password you provided. However deploy from TFS will use the build agent. So, the first thing is that the service account of the build process should has the correct permission to access the remote server.
Just try to give the build service account local administrator permissions and IIS Manager Permissionson to the site's scope on the remote server ("MySERVER"). Then set the username parameter to "" (empty quotes) and the password field omitted.
Reference: Build only works with username and password in msbuild arguments
This error code can surface because of a number of different reasons.
It typically indicates an authentication or authorization problem, and
can happen because of any of hte following reasons:
If connecting using the Web Management Service:
Verify that the username and password are correct
Verify that the site exists
Verify that the user has IIS Manager Permissions to the site's scope
If connecting using the Remote Agent Service:
Verify that the username and password are correct
Verify that the user account you specified is a member of the Administrators group on the remote computer. NOTE: Because of a bug
in Web Deploy 2.0, the user must be either the built-in Administrator
or a member of the Domain Administrators security group. Attempts to
sync with any other user account, even if it is an administrator,
will see this error code. Verify that the site exists
Reference : ERROR_USER_UNAUTHORIZED
UPDATE:
By default, Web Deploy will connect using HTTP Basic Authentication.
When using HTTP Basic Authentication, specific credentials must be supplied,
e.g.
msdeploy.exe -verb:dump -source:apphostconfig,wmsvc=demo-host,authType:basic,username=someuser,password=somepassword
In your scenario, you can try set the AuthType as NTLM, then try it again.
Just try adding the line <AuthType>NTLM</AuthType> to the publish .pubxml file.
Try this:
On your server go to Computer Management
From the left pan select Local Users and Groups
Go to users find the tfsadmin user
Right click on it and click on Set Password
Give your existing password (whatever it is)
This seems unnecessary but worked for me. I hope someone can explain the "why".

Sonar with ldap plugin does not use LDAP without domain prefix

I'm using sonar 5.6 LTS with LDAP plugin 2.1.0.
The basic LDAP configuation is working fine. Sonar can connect to LDAP (in my case active directory). sonar.log:
Test LDAP connection on ldaps://ldap.mycompany:636: OK
My user mapping is
ldap.user.baseDn=OU=Users,OU=Accounts,DC=mycompany
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
When I try to login with mycompany\tobi sonar logs:
DEBUG web[o.s.p.l.LdapUsersProvider] Requesting details for user mycompany\tobi
...
DEBUG web[o.s.p.l.LdapUsersProvider] User mycompany\tobi not found in <default>
This makes sense as sAMAccountName contains the value tobi and not mycompany\tobi. But when using just tobi as login, sonarqube does not connect to LDAP for authentication. I just get "Authentication failed" and the log file contains only
DEBUG web[http] POST /sonar/sessions/login | time=235ms
Any ideas why sonarqube does not always use LDAP? Thanks, Tobi
Thanks to Godin, I've finally found the answer:
The root cause is that I had a local account with the same login credentials before using LDAP. When removing users using the web interface, they are not removed permanently from the database. Instead, they are just deactivated.
I connected to the (postgresql) database and in the users table there were still all old local accounts. So I just changed the login column of all deprecated local accounts with
UPDATE users SET login='username_local' WHERE login='username'
As those accounts are deactivated, they cannot be used to login into sonarqube but should not be removed as some other tables might still have references to them.

SonarQube: Can't Create Technical User

SonarQube v5.2
I am trying to create a technical user (one that is authenticated locally and not against our LDAP). I have added a user name to the conf/sonar.properties file and restarted SonarQube. But, when I log in (as an administrator), the new user doesn't show up in the Administration | Security | Users list. We have two previously defined technical users (including admin) which do show up.
The admin guide doesn't say much http://docs.sonarqube.org/display/SONARQUBE52/Authentication.
Is there another step needed to create a technical user?
You need to manually create the user in SonarQube, it won't be automatically at startup.
Note that the SonarQube version you're using is no more supported, you should migrate to the latest LTS version 5.6.X => local users (previously known as technical users) are better managed :
- No more need to update sonar.properties
- You just have to create a user from the web server, this user will automatically be considered as a local user.
I've updated http://docs.sonarqube.org/display/SONAR/Authentication in order to remove the "Technical" word.

Liferay LDAP Authentication does not work properly

I am using Liferay 6.2 and I am trying to do LDAP Authentication. The LDAP Server is provided by another organization and I do not have access to any configuration, I just have credentials for a system account to look up the directory. When I try to log in Liferay with user credentials from the LDAP Server the authentication fails with the following error code:
13:54:05,738 ERROR [http-bio-8080-exec-3][LDAPAuth:341] Problem accessing LDAP server
javax.naming.NameNotFoundException: [LDAP: error code 32 - 0000208D: NameErr:
DSID-0315270B, problem 2001 (NO_OBJECT), data 0, best match of:
'O=uni,C=de' remaining name 'ou=people,o=uni,c=de'
The same error that occurs when trying to log in with a user that does not exist in the LDAP directory. Nevertheless, the mapping still works. After trying to log in with valid user credentials there is an entry in the liferay database with the corresponding user data. Accessing Liferay is not possible though.
These are my settings in portal-ext.properties (Test LDAP connections returns success, connection settings are pseudonymised):
ldap.base.provider.url=ldaps://ldap.ldap-server
ldap.base.dn=ou=people,o=uni,c=de
ldap.security.principal=uid=prox,ou=prox,o=uni,c=de
ldap.security.credentials=secret
#auth.pipeline.enable.liferay.check=false
ldap.auth.enabled=true
ldap.auth.required=true
ldap.auth.method=bind
ldap.import.enabled=false
ldap.import.on.startup=false
ldap.import.interval=10
ldap.export.enabled=false
ldap.export.group.enabled=false
ldap.auth.search.filter=(uid=#screen_name#)
ldap.import.user.search.filter=(objectClass=inetOrgPerson)
ldap.attrs.transformer.impl=com.liferay.portal.security.ldap.DefaultAttributesTransformer
ldap.user.mappings=screenName=cn\npassword=userPassword\nfirstName=givenNam\nlastName=sn\njobTitle=title\ngroup=groupMembership
users.email.address.required=false
users.email.address.auto.suffix=#no-emailaddress.com
users.email.address.generator=com.liferay.portal.security.auth.DefaultEmailAddressGenerator
users.email.address.validator=com.liferay.portal.security.auth.DefaultEmailAddressValidator
ldap.password.policy.enabled=false
ldap.import.user.password.enabled=true
ldap.import.user.password.autogenerated=false
ldap.import.user.password.default=test
Check the FQDN on the LDAP side, including the prefixes (cn, ou, etc.), and ensure that it matches the directory configuration within Liferay.
You can try configuring it from the control panel it will be easier for you as it allows to check whether the connection is made or not. You can check the users are fetched or not and it doesnt even need a server restart.
It works now. There were two issues:
I changed ldap.base.dn=ou=people,o=uni,c=de to ldap.base.dn=o=uni,c=de and
ldap.import.user.search.filter=(objectClass=inetOrgPerson) to ldap.import.user.search.filter=(objectClass=*)

IBM Worklight 5.0.5 - How to configure LDAP for Application Center using WAS ND 8.0.1?

We've been trying without much success to enable LDAP user authentication for the Worklight Application Center. We've carefully followed the instructions here:
http://pic.dhe.ibm.com/infocenter/wrklight/v5r0m5/index.jsp?topic=%2Fcom.ibm.help.doc%2Fwl_home.html
First, we created the LDAP repository in the WAS console and added it to the federated repositories config:
http://pic.dhe.ibm.com/infocenter/wrklight/v5r0m5/index.jsp?topic=%2Fcom.ibm.worklight.help.doc%2Fappcenter%2Fc_ac_was8_ldap.html
Then we configured the LDAP authentication for users and groups following:
http://pic.dhe.ibm.com/infocenter/wrklight/v5r0m5/index.jsp?topic=%2Fcom.ibm.help.doc%2Fwl_home.html
Finally we enabled ACL management with LDAP as suggested by:
http://pic.dhe.ibm.com/infocenter/wrklight/v5r0m5/index.jsp?topic=%2Fcom.ibm.help.doc%2Fwl_home.html
After the server restart these are the results:
Worklight Console: Works OK.
Application Center: Shows a ?????? in the user space with the following error in every screen related to users: FWLAC0401W: No user appears to be logged, check the Application Center security configuration.
Worklight WAS Console: We are locked out. The LDAP users do not work, the initial worklight/worklight user does not work. The only way to get in is changing the security.xml for the instance to get back in and rollback the security changes.
What are we doing wrong?
Is there a more "tutorial like" documentation to accomplish these tasks, we might be making some mistakes following the infocenter.
About the application center effect: Technically, the message means that the Web Security Context does not contain a principal (i.e. a user name). In general, Application Center must be configured so that the login screen appears (is this the case for you?).
I know two possible reasons:
Application Security is disabled in WAS. Open the WAS console and select Security > Global Security. Ensure that "Enable Application Security" is checked. Ensure also that "Enable Administrative Security" is checked.
The appcenteradmin role is mapped to special subject "Everyone". Both the appcenteradmin role and the appcenteruser role cannot be mapped to this special subject, because it simply disables the authentication and hence the security context does not know anymore which user is logged in. Look in Applications > Application Types > WebSphere Enterprise Applications > AppCenter > Security Role to user/group mapping. Here you can see how the roles are mapped and you can change it.
Since you also have a problem with the Worklight WAS console, I would guess that your situation is 1., since 2. is local to the Application center and does not affect the WAS console.