[keycloak-user] Issues with Keycloak and AD

Charles Hardin chardin at shadowforge-computing.com
Thu Apr 27 07:33:59 EDT 2017


Marek,

I tried turning that on and it led me to a discovery. When I looked at the
trace log, MSAD was refusing the password, even though I could manually
create a user with the same password.

Some googling lead me to the fact that AD will not allow an ldap connection
to manipulate a password. It requires ldaps. Once I changed my connection
to ldaps and setup the truststore with the cert, its now creating users as
expected.

Thanks!

On Wed, Apr 26, 2017 at 12:14 AM, Marek Posolda <mposolda at redhat.com> wrote:

> Could you try to enable TRACE logging for category "org.keycloak.storage.ldap"
> in standalone.xml and then see what's logged into server.log at the moment
> when you sent request to register new user?
>
> Thanks,
> Marek
>
> On 26/04/17 04:58, Charles Hardin wrote:
>
> Marek,
>
> I did some more testing on my side. I made the user Keycloak uses to talk
> to MSAD a Domain Admin(I was using delegation). I dropped the domain and
> forest functional level to 2012R2, and also removed the realm and recreated
> to make sure I was as close to defaults as I could be.
>
> I went and dug through the AD events, and it looks like for whatever
> reason Keycloak is creating the user with a UAC value of 0x15.
>
> Old UAC Value:        0x0
> New UAC Value:        0x15
> User Account Control:
>         Account Disabled
>         'Password Not Required' - Enabled
>         'Normal Account' - Enabled
>
> Here is what Keycloak logs when it connects the ldap:
>
> 22:12:06,563 INFO  [org.keycloak.storage.ldap.LDAPIdentityStoreRegistry]
> (default task-4) Creating new LDAP Store for the LDAP storage provider:
> 'ldap', LDAP Configuration: {pagination=[true], fullSyncPeriod=[604800],
> usersDn=[<REMOVED>], connectionPooling=[true], cachePolicy=[DEFAULT],
> useKerberosForPasswordAuthentication=[false], importEnabled=[true],
> bindDn=[<REMOVED>], changedSyncPeriod=[86400], usernameLDAPAttribute=[sAMAccountName],
> lastSync=[1493169877], vendor=[ad], uuidLDAPAttribute=[objectGUID],
> connectionUrl=[<REMOVED>], allowKerberosAuthentication=[false],
> syncRegistrations=[true], authType=[simple], debug=[false],
> searchScope=[1], useTruststoreSpi=[ldapsOnly], priority=[0],
> userObjectClasses=[person, organizationalPerson, user],
> rdnLDAPAttribute=[cn], editMode=[WRITABLE], batchSizeForSync=[1000]},
> binaryAttributes: []
>
>
> Not quite sure where to go with this. Is there a way to get keycloak to
> log the user creation attempt somewhere?
>
>
>
> On Tue, Apr 25, 2017 at 4:15 PM, Marek Posolda <mposolda at redhat.com>
> wrote:
>
>> On 25/04/17 16:07, Charles Hardin wrote:
>>
>> I tried turning that off, but the problem seems to persist. I also
>> changed minimum password age to 0 on the AD site and it still fails to
>> change the pasword.
>>
>> The AD configuration is pretty much default outside of password
>> configuration.
>>
>> The user gets created in AD with the must change password at next login
>> flagged, as well as account disabled.
>>
>> I will keep poking on my end to see what I can find. Any guess when it
>> might be testable against 2016 on your side?
>>
>> Not sure. Depends on the priorities and how much customers need that.
>>
>> Marek
>>
>>
>>
>> On Tue, Apr 25, 2017 at 3:33 AM, Marek Posolda <mposolda at redhat.com>
>> wrote:
>>
>>> I was not able to simulate the issue with MSAD 2008 or MSAD 2012. I have
>>> same setup as you (Password Policy Hints enabled, Writable edit mode).
>>>
>>> After the registration is user's password successfully updated in MSAD
>>> and I can see that MSAD attributes of user are in expected state
>>> (pwdLastSet is updated to latest time, userAccountControls are in 512,
>>> which corresponds to fully created and enabled user).
>>>
>>> Not sure if the difference is with your MSAD setup or if this is related
>>> to MSAD 2016. We don't yet test with this version for now.
>>>
>>> The workaround might be to disable "Password Policy Hints". But then
>>> some advanced password policies won't work (password history etc).
>>>
>>> Marek
>>>
>>>
>>> On 21/04/17 15:42, Charles Hardin wrote:
>>>
>>> 2016
>>>
>>> On Fri, Apr 21, 2017 at 7:57 AM, Marek Posolda <mposolda at redhat.com>
>>> wrote:
>>>
>>>> I will try to reproduce that. What's your MSAD version btv?
>>>>
>>>> Thanks,
>>>> Marek
>>>>
>>>>
>>>> On 20/04/17 23:55, Charles Hardin wrote:
>>>>
>>>>> Hello All,
>>>>>
>>>>> I have setup an instance of Keycloak 3 and connected it to AD. It is
>>>>> setup
>>>>> to sync users and is writeable edit mode. I also have Pasword Policy
>>>>> Hints
>>>>> enabled in the MSAD Account Controls mapper. I have user registration
>>>>> turned on in Keycloak.
>>>>>
>>>>> When I register a user in keycloak, it creates the user in a disabled
>>>>> state
>>>>> in AD, and prompts the user in keycloak to change the password they
>>>>> just
>>>>> set during account creation to activate the account. This then fails
>>>>> because AD is currently configured to enforce a minimum password age
>>>>> of one
>>>>> day.
>>>>>
>>>>> I am ok with the account being created disabled, but how do I get
>>>>> around
>>>>> the immediate 2nd password request?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Chuck
>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


More information about the keycloak-user mailing list