We got a Problem regarding the AD-Sync. In our Federation-Conf the "Edit Mode" is Unsynched, Version of Keycloak is 15.0.2.
Sometimes it is behaving like Read-Only because you can't manually enable disabled user. If you click on enable:on, it right jumps back to enable:off
Some Users, which are disabled, can't get enabled per AD-Sych.
Also there is discrepancy between UI and DB, in the UI the User is disabled in the DB he/she is enabled.
This is so strange, and we deleted the cache. One thing we suspect is the infinispan cache...
You may experience this behaviour because there may be a MSAD account controls mapper configured with your user federation. When that mapper is configured, Keycloak will "merge" the user state (enabled/disabled) from AD with the state stored in Keycloak. If either is disabled, Keycloak will mark the user as disabled.
Since you are using unsynched mode, Keycloak will only update its own database, but not the information stored in AD.
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.
I've set up Zoom and DocuSign with SSO and Automatic provisioning in Azure AD Enterprise Applications. Just in Time provisioning works as expected after ensuring roles are correctly mapped. Automatic provisioning however only appears to add users the first time it runs. If I add an application user, change a user's Application Role, or Remove the user from the application nothing happens on the next provisioning run. I would expect the user to be added, the user's permissions to be updated at Zoom or DocuSign, or for the user to be disabled.
Documentation seems to show that updates and deletes should be handled through provisioning. What am I missing?
Second question is whether the timing of how often provisioning job runs can be changed. It is time consuming to test when I have to wait 40 minutes between tests.
updates and deletes are handled if they are configured to. https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/configure-automatic-user-provisioning-portal#configuring-automatic-user-account-provisioning
in the screenshot, you'll see there is actions that it can target, create, update, delete. if those are all selected, As a test, you should make sure the target actions are selected and try to change a different attribute, say add some characters to a name or something. it should trigger and update to the provider.
I believe changes of the User itself will trigger the provisioning changes,
The issue here is likely because app roles are specific to applications, they are not user or group attributes, nothing has actually changed on that user object. so it wouldn't detect any changes.
as per: https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/how-provisioning-works#incremental-cycles
it will "Query the source system for any users and groups that were updated since the last watermark was stored."
if I take that literally, then changing the app role isn't a change to a user or a group, so it won't trigger a delta sync change
Deletes however should occur, if you unassign the user from the application. as per here: https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/how-provisioning-works#de-provisioning
as for your second question, the interval I don't believe you can change that for the incremental schedules.
We have the angularjs application where we have different roles associated to the users. For ex: the two roles are Admin and Local. Based on the role, we show some menu items for the Admin and adds more features/screen to the Admin .
The userInfo with the Admin Property is returned from the login response and based on what we decide which all menu and screens to be rendered .
But if we user the developer tool, and the set the break point where the admin property is used, and set the admin property as true the user even he is a local user would be able to access admin privileges .
In short who has some idea about the javascript code can get the admin privileges . Is there any idea other than minification of the code to prevent this kind of security threats
Thanks
As the front-end of your application will run on the client machine there is actually no way to stop a user from debugging or modifying the code. Thus it's impossible to prevent someone from tricking their local instance of the application to think it's signed in as an administrator.
If you simply want to hide the admin interface, one possibility is to have separate (or additional) templates for administrators and restrict access to these based on the user's privilege. If there is anything to be gained from this is up to you. You will still need to validate the rights to execute any privileged action on the server anyway. Obtaining administrative privileges on the client must never be the same as obtaining them on the server side.
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 am trying to get user's online status during login. I am checking following property after ValidateUser, but it always return false.
objUser.Membership.IsOnLine
Just to confirm, i put following code in one of my module that can be accessed ONLY after login.
Dim _currentUser As UserInfo = DotNetNuke.Entities.Users.UserController.GetCurrentUserInfo()
Dim message as String = IIf(_currentUser.Membership.IsOnLine, "Online", "Not Online")
UI.Skins.Skin.AddModuleMessage(Me, message, Skins.Controls.ModuleMessage.ModuleMessageType.BlueInfo)
It always show 'Not Online', while user is logged in.
Am i missing something?
Please help.
I am using DNN 6.02.05 Community Ed.
Important steps to Enable Online Users in DotNetNuke
The “Users Online” module works on a background thread (via the scheduler) to add and expire users from the users online list. The scheduled job should exist in your installation, but it is disabled by default.
To enable the scheduled job:-
Login to your portal as a Super User account (e.g. host)
Navigate to Host -> Schedule
Edit the “DotNetNuke.Entities.Users.PurgeUsersOnline, DOTNETNUKE” job (click the pencil)
Check “Scheduled Enabled”
Click Update
Click 'run now' to get effect on the spot.
Now that you have configured the scheduled job, your users should begin to process background users. The problem is that there is an additional host setting you must set before this can occur.
To enable users online:-
Login to your portal as a Super User account (e.g. host)
Navigate to Host -> Host Settings
Expand “Other Settings”
Check “Enable Users Online”
Click Update
maybe a dumb question, but did you check whether users online feature is turned on in the host settings --> other settings?