Repository navigation
Replies: 1 comment
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
{{ message }}
<
8000
div itemscope itemtype="http://schema.org/SoftwareSourceCode" class="">
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji
reacted with thumbs down emoji
reacted with laugh emoji
reacted with hooray emoji
reacted with confused emoji
reacted with heart emoji
reacted with rocket emoji
reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hi,
I have implemented SAML as an Identify Provider, and Active Directory on User Federation.
My goal is this:
1 - A user authenticate via SAML
2 - The user is created automatically
3 - A random password is generated, so that the user is unlocked in Active Directory
4 - The user account in AD is unlocked.
What I accomplished so far:
By setting up
userPasswordandpwdLastSetmappers for the ldap provider, I manage to create an "enableble" account on the console. When I create a new user, it is by default disabled (probably because of the msad-user-account-control mapper), but clicking on "enable" does enable the account on AD. My goal was that the user would be enabled by the default, but it isn't.But the situation is even worse when the user creation happens via the client:
When the user logs in via SAML, the user is indeed create in the AD, but neither the userPassword nor the
pwdLastSethave values, which means that theupdate passwordrequired option for the user in the console does not go away. I don't know why the ldap mappers do not work when this user comes from a SAML authentication.It seems there are two problems:
1 - Keycloak does not have an option to update/apply the
userAccessControlattribute to the user after its creation. It does update it after a credential is set manually.2 - There is probably a bug that prevent hardcoded user attribute mappers to be applied when the user is created automatically, like for example when the user creation is triggered by a first time login via a SAML identity provider.
But either way, what could I do to accomplish the above mentioned goals - that is - when a user logs in for the first time via SAML, I want it to be created in the AD and enabled right away.
I am considering writing code to apply a standard "512" code (0x0200) to the
userAttributeControl, so that the user can be enabled by default.Best,
Francis
All reactions