Bug 1130316 - IPA account is not locked when max failures are exceeded for GSSAPI
Summary: IPA account is not locked when max failures are exceeded for GSSAPI
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: ovirt-engine-extension-aaa-ldap
Classification: oVirt
Component: Profile.ipa
Version: 1.0.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified vote
Target Milestone: ---
: ---
Assignee: Alon Bar-Lev
QA Contact: Ondra Machacek
URL:
Whiteboard: infra
Depends On:
Blocks: oVirt-AAA-LDAP
TreeView+ depends on / blocked
 
Reported: 2014-08-14 20:30 UTC by Ondra Machacek
Modified: 2016-02-10 19:01 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-09-01 08:19:46 UTC
oVirt Team: Infra


Attachments (Terms of Use)

Description Ondra Machacek 2014-08-14 20:30:16 UTC
Description of problem:


Version-Release number of selected component (if applicable):
ovirt-engine-extension-aaa-ldap-0.0.0-0.0.1.master.el6_5.noarch
ovirt-engine-3.5.0-0.0.master.20140804172041.git23b558e.el6.noarch

How reproducible:
always

Steps to Reproduce:
1. setup ipa with gssapi
2. add user and asign him permissions
3. try to login with user more times then is allowed to lock account.

Actual results:
user account is not locked

Expected results:
user account is locked

Additional info:
works fine for simple auth.
------- properties file -----------
include = <ipa.properties>
vars.user = lock_test
vars.password = 123456
vars.domain = rhev.lab.eng.brq.redhat.com
vars.server = brq-ipa.${global:vars.domain}
vars.dns = dns://brq-ipa.${global:vars.domain}

pool.default.serverset.type = srvrecord
pool.default.serverset.srvrecord.domain = ${global:vars.server}
pool.default.auth.type = gssapi
pool.default.auth.gssapi.authenticationID = ${global:vars.user}
pool.default.auth.gssapi.password = ${global:vars.password}
pool.default.auth.gssapi.allowedQoP = AUTH, AUTH_CONF, AUTH_INT
pool.default.ssl.startTLS = false
pool.default.ssl.enable = false
sequence-init.init.000-krb-init = krb-init
sequence.krb-init.0.description = system kerberos settings
sequence.krb-init.0.type = sysprop-set
sequence.krb-init.0.sysprop-set.name = java.security.krb5.conf
sequence.krb-init.0.sysprop-set.value = ${local:_basedir}/krb5_ipa.conf
sequence.krb-init.1.description = system kerberos settings
sequence.krb-init.1.type = sysprop-set
sequence.krb-init.1.sysprop-set.name = java.security.auth.login.config
sequence.krb-init.1.sysprop-set.value = jaas.conf

----- kerberos config ------

[libdefaults]
        dns_lookup_realm = false
        ticket_lifetime = 24h
        renew_lifetime = 7d
        forwardable = false
        default_realm = BRQ-IPA.RHEV.LAB.ENG.BRQ.REDHAT.COM

[realms]
        BRQ-IPA.RHEV.LAB.ENG.BRQ.REDHAT.COM = {
                kdc = brq-ipa.rhev.lab.eng.brq.redhat.com
                admin_server = brq-ipa.rhev.lab.eng.brq.redhat.com
        }

[domain_realm]
        .brq-ipa.rhev.lab.eng.brq.redhat.com = BRQ-IPA.RHEV.LAB.ENG.BRQ.REDHAT.COM
        brq-ipa.rhev.lab.eng.brq.redhat.com = BRQ-IPA.RHEV.LAB.ENG.BRQ.REDHAT.COM

Comment 1 Alon Bar-Lev 2014-08-15 02:23:12 UTC
this cannot be a bug in the client... but the server... in this case ipa.

server cannot be expected that the client takes care of user locking... or it is totally insecure.

same can probably introduced using simple kinit.

also, please try to push back testing of kerberos, it is not priority at all, priority is plain ldap.

Comment 2 Alon Bar-Lev 2014-08-17 10:28:34 UTC
 Itamar Heim 2014-08-17 06:27:23 EDT
Target Release: --- → 3.5.0

not our bug.

Comment 3 Alon Bar-Lev 2014-08-19 11:46:19 UTC
0. using kerberos is not a priority for the generic ldap.

1. please do not use sequences for system properties settings but /etc/ovirt-engine/engine.conf.d/xxx.conf::ENGINE_PROPERTIES

2. pool.default.auth.type = gssapi is sufficient, no need for the other settings.

3. there are other variables that are needed to be set in order to have successful kerberos configuration, I will send you these.

The subject is misleading, it is not related to ipa specific as no authentication is actually done per what you wrote me.

Comment 4 Alon Bar-Lev 2014-08-19 14:31:53 UTC
ok, I am beginning to understand what you have done... you try to use locked user as search user... what I am guessing happens is that the when bind fails it remains in anonymous bind, and as anonymous bind can access all objects you have full functionality.

however, using:

vars.user = my_test
vars.password = fake
pool.authz.auth.type = gssapi

at initialization I get:

2014-08-19 17:11:01,467 DEBUG [org.ovirt.engineextensions.aaa.ldap.Framework] (DefaultQuartzScheduler_Worker-34) Exception during sequence: LDAPException(resultCode=32 (no such object), errorMessage='no such object')
        at com.unboundid.ldap.sdk.LDAPConnection.bind(LDAPConnection.java:2178) [unboundid-ldapsdk.jar:2.3.7]
2014-08-19 17:11:01,482 ERROR [org.ovirt.engine.core.bll.aaa.SyncUsers] (DefaultQuartzScheduler_Worker-34) Error during user synchronization of extension ldap-authz-ipa1. Exception message is no such object

at authentication I get:

2014-08-19 17:30:02,131 ERROR [org.ovirt.engine.core.bll.aaa.SyncUsers] (DefaultQuartzScheduler_Worker-34) Error during user synchronization of extension ldap-authz-ipa1. Exception message is An error occurred while attempting to initialize the JAAS login context for GSSAPI authentication:  javax.security.auth.login.LoginException: Integrity check on decrypted field failed (31) - PREAUTH_FAILED caused by KrbException: Integrity check on decrypted field failed (31) - PREAUTH_FAILED caused by KrbException: Identifier doesn't match expected value (906)

so I cannot reproduce this using locked user.

now... a configuration in which a end user is authenticated using gssapi is completely different... you should add the following to configuration:

auth-check.ad-authn.auth.type = gssapi

then with latest extension (7d503c) add the following into the authn extension properties file:

config.globals.bindFormat.simple_bindFormat = realm

there is no much sense in using gssapi to authenticate end-users as the ldap plays no part in authentication, better to implement gssapi authn extension to do so, get the user principal and use the ldap authz.

this is why kerberos is last priority.

Comment 5 Alon Bar-Lev 2014-08-19 14:48:54 UTC
ok, I think the problem is you did not set:

 pool.authz.auth.type = gssapi

Comment 6 Oved Ourfali 2014-08-25 06:29:38 UTC
Ondra - can you verify that?

Comment 7 Alon Bar-Lev 2014-08-27 17:48:04 UTC
until issue cannot be determined, priority cannot be high nor target release can be set.

Comment 8 Ondra Machacek 2014-10-09 12:58:43 UTC
Works fine with:
auth-check.default.auth.type = gssapi
pool.authz.auth.gssapi.authenticationID = lock_test
pool.authz.auth.gssapi.password = change

account is locked.


Note You need to log in before you can comment on or make changes to this bug.