In our SonarQube 5.4 we authenticate in Active Directory using LDAP plugin and specifying just one property in sonar.properties:
sonar.security.realm=LDAP
(according to http://docs.sonarqube.org/display/PLUG/Microsoft+Active+Directory)
It's a shame they removed the feature to disable updating user properties on every login:
sonar.security.updateUserAttributes = false
See this:
https://jira.sonarsource.com/browse/SONAR-7219
We've been using it, as update on every login removes assignment of users to SonarQube built-in groups, e.g. sonar-administrators.
I can give individual users whatever rights in Administration > Security > Global Permissions, but I'd prefer to do this for SonarQube groups, as we have lots of users.
Reflecting the whole setup of groups in AD is difficult, as our Infrastructure teams are too slow and bureaucratic
Is there any other way to achieve what we want?
UPDATE
I've tried configuring empty values for group properties:
ldap.group.baseDn=
ldap.group.request=
ldap.group.idAttribute=
But it doesn't help - every login group membership is resynchronized again from AD and membership in internal SQ groups is removed.
In order to disable group synchronisation from LDAP, you can simply remove properties ldap.group.*.
See "Group Mapping" http://docs.sonarqube.org/display/PLUG/LDAP+Plugin.
link to post
Related
I'm creating a set of hands-on lab users in my Azure AD for access to Azure Labs. We will reuse these user accounts (and reset the passwords after every lab session).
My challenge is that these users are being required to configure MFA. Which I THINK is called the Azure AD Interrupt Mode described here.
Is there a way to exclude these group of users from being required to set this up?
I think this can be disabled entirely by navigating to Azure AD - Default Directory - Properties - Manage Security Defaults (right at the bottom of the page) - Enable Security Defaults - set it to No.
If it's per user basis, then Navigate to Azure AD - All users - Per User MFA - this will list all the users and then you can select "n" number of them to either enable or disable MFA.
// Answering my own question and hope it helps someone.
The first and obvious step is to disable MFA. This is described in this link: https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates
After this, however, you may still face the interrupt wizard as shared in the screenshot of the question above. This is due to Self-Service Password Reset (SSPR) being enabled. If SSPR is enabled, then MFA is still required for them to be able to do a password reset.
Solution 1: If you want SSPR enabled, then create a Conditional Access policy requiring MFA upon sign in.
This way, MFA is only triggered when user wants to do an SSPR.
For this lab user scenario, you will still have to set-up MFA one-time for each of the users (you may use the same contact details).
Extra note: I tried setting the MFA details by bulk using PowerShell. However, it is not possible to set an MSOL user object's StrongAuthenticationUserDetails property.
Solution 2: Disable SSPR or limit to selected users using AD groups
Don't include the lab users in the selected users group. Since SSPR is not allowed for these users, the extra MFA details won't be asked of these users anymore.
Drawback: The setting is to include user groups which should have SSPR. There's no option to exclude just the lab users.
Solution 2 works for me but may not work for everyone.
My team just "inherited" an Archer setup with 2 ADs and LDAP sync setup for each of them. The LDAP sync works fine individually; we are able to see the users/groups as per the LDAP configuration's filters. However, we have some groups in AD#1, that contain users from AD#2 and the LDAP sync is only showing/pulling users from 1 AD in Archer. I'm on Archer 6.4.
My question:
Is it possible at all in Archer to get the groups to show members from the 2 AD's?
Does the LDAP service account need any special permissions?
Anything else that I'm missing, or any viable workarounds?
I have looked at this question which talks about some possibilities but it's quite old so starting a new question. Any help is greatly appreciated.
The question you referenced is related to Archer v5.x and v6.x, so everything I mentioned there is still valid as of 2019-04-26.
Back to the questions you asked:
Is it possible at all in Archer to get the groups to show members from the 2 AD's?
The answer is "Yes", but not that simple.
If you check tables on the back end you can see that there are two type of groups:
Manually created groups by Archer admins. These groups are not part of any LDAP source and you can't synch these groups/users.
Groups created via LDAP Synch. These groups and users are synched with LDAP Synch configuration.
In your case, if you have two LDAP synchs configured then you will have two sets of LDAP groups and two sets of LDAP users, assuming LDAP synch is configured to add and synch groups and users using filters correctly.
Based on what you shared if you have group "ABC" in both LDAP sources you will have two groups added to Archer. On the back end in the table tblGroup they will have different "ldap_config_id" values, but same name.
Same applies for users - if you have user "User1" in both LDAP sources you will end up with two users with different domains and different "ldap_config_id".
Back to your question - Yes, if you have two LDAP sources with same group name you will end up with two groups with same name, each group should have users from corresponding LDAP assigned, if you configured both LDAP synchs to add and synch groups and users.
If this doesn't work this way for you, then review your LDAP synch configuration. Your may not have an option enabled to synch groups or don't have any filters in place to get them.
Does the LDAP service account need any special permissions?
In Archer - no, but in LDAP source (Active Directory) the account you specified in LDAP configuration should have access to query certain areas. The account you use for 2nd LDAP may not have access to query groups. I'm not an expert in AD security, you should talk to AD admin on this matter.
Anything else that I'm missing, or any viable workarounds?
See the old question/answer you referenced. LDAP synch principals in Archer v5 and v6 are the same as I know.
Best solution in my opinion is to establish "virtual link" or trust between both Active Directories. Third AD can be created with both AD#1 and AD#2 merged or linked. This way you can query AD#3 and have groups and users provided for you by using only one LDAP synch configuration/Domain. This is the simplest solution for you, but your AD admin will have to do some work.
You can check other options in the old question as well.
P.S: the instance I develop for had 2 LDAP sources, but I configured them to have unique group names and unique users. This way collisions don't occur.
Good luck!
Hahn, I'm uncertain how Archer handles users from two different AD's that members in the same group found in the first AD.
It's best to reach out to Archer support and pose the question to them.
I'm also seen a simlar question in RSA Partner Community. Support may respond to that post then here or other clients that have had the same issue.
I am checking SonarQube 5.4 and the latest LDAP plugin 1.5.1. There are however a couple of issues.
First. My AD account is majcicam. If I log in with it, it is correctly shown in the users list. However if I login with MajcicaM (note capital letters) another additional user is added to the list:
As you can see from the attached image. For every login that I do make, seems it is treated as case sensitive and thinks of it as a different user.
Second thing. Once I assign a group to my user, on the next login those settings are gone. Seems that they are not persisted.
Am I doing something wrong? Is this a bug? Are my settings messed up?
Thanks
Mario
No bugs here, just some subtleties about LDAP Plugin configuration and behaviour. :)
Case-insensitive login
Set sonar.authenticator.downcase to true when delegating authentication to an LDAP/AD server which is case-insensitive.
Group mapping behaviour
When group mapping is configured (i.e. you manually configured ldap.group.* or you use the windows authentication mode with lightweight AD config), membership in LDAP/AD will override any membership locally configured in SonarQube. LDAP/AD becomes the one and only place to manage group membership (and the info is fetched each time the user logs in).
I use Exchange 2003 and I have been searching a lot and found related queries like
(&(UserAccountControl:1.2.840.113556.1.4.803:=2)(msExchHomeServerName=*)(objectClass=User))
Which enumerates disabled user accounts with mailboxes, but what I want is quite the opposite, user accounts (enabled or disabled) with CLOSED mailboxes. Thanks beforehand for any help!
Exchange and Active Directory are separate, if user is created on AD doesn’t mean that it will have mailbox account too but usually both are used together.
You can use any LDAP browser like JXplorer or LDAPadmin to check the settings for your users on Active Directory. You will find disabled users on AD moved to different OU or there should be some attribute which will differentiate it from active users.
You can export LDIF file (by LDAP browser like LDAPadmin) for one active user and one disabled user and compare both to find relevant attribute for disabled entity and use it for your query filter. You can consult your IT team also who is managing Active directory for more details. HTH :)
I'm trying to restrict TeamCity users to members of a specific AD group (FNC_TEAMCITY_USERS). LDAP user synchronisation was already working. In my ldap-config.properties I changed this:
teamcity.users.filter=(objectClass=user)
to this:
teamcity.users.filter=(&(objectClass=user)(memberOf=CN=FNC_TEAMCITY_USERS,OU=Groups,DC=group,DC=ourdomain,DC=com))
I restarted the TeamCity service and this change had no effect. All AD users can still log in to TeamCity. I tried this on both our 6.5 instance and our 7.0 (EAP) instance.
Is there something I've missed or is this a bug?
The property limiting users who can login into TeamCity is "teamcity.users.login.filter". Try setting it instead of "teamcity.users.filter".
"teamcity.users.filter" is the one affecting users synchronization (particularly creating users in TeamCity for users in LDAP).
Be sure to have "java.naming.security.principal" and "java.naming.security.credentials" correctly specified as they are required for "teamcity.users.login.filter" use.