+++ This bug was initially created as a clone of Bug #1156577 +++

Description of problem:

After upgrading from IPA 6.4 to IPA 6.6, unable to add domains via engine-manage-domains


Version-Release number of selected component (if applicable):

RHEV 3.x

IPA:
#  rpm -qa ipa-{server,client} 389-ds-*
ipa-server-3.0.0-42.el6.x86_64
389-ds-base-libs-1.2.11.15-47.el6.x86_64
389-ds-base-1.2.11.15-47.el6.x86_64
ipa-client-3.0.0-42.el6.x86_64

How reproducible:

100%


Steps to Reproduce:

* Install IPA 6.6
* Use engine-manage-domain to add an IPA domain


Actual results:

# rhevm-manage-domains add --domain=example.com --provider=IPA --user=admin
Enter password:
General error has occurednull
java.lang.NegativeArraySizeException
	at sun.security.jgss.krb5.CipherHelper.aes256Encrypt(CipherHelper.java:1367)
	at sun.security.jgss.krb5.CipherHelper.encryptData(CipherHelper.java:722)
	at sun.security.jgss.krb5.WrapToken_v2.<init>(WrapToken_v2.java:200)
...
Failure while testing domain %1$s. Details: %2$s: One of the parameters for this error is null and no default message to show



Expected results:

Domain is added.


Additional info:


This has been brought up before, and the response was to change minssf from 0 to 1 to avoid a JVM error.  However, minssf for IPA in RHEL 6.4 was 0 as well, and worked fine, so there is something else happening.

In addition, setting minssf to anything greater than 0 has a negative effect on OpenStack installations configured to use the same IPA server.  Bug forthcoming for that as well.

In essence, customers using RHEV and OpenStack, and using a central IPA server to manage users in these environments could find themselves in a situation where all three products will no longer work together.  This is the first bug of three to raise awareness to this.

I have attached:
* capture file from 6.4 IPA server for LDAP "conversation" when adding the domain via engine-manage-domains

--- Additional comment from James W. Mills on 2014-10-24 13:08:54 EDT ---



--- Additional comment from Alon Bar-Lev on 2014-10-24 13:12:55 EDT ---

please try to use the ovirt-engine-extension-aaa-ldap in this configuration and not legacy. moving bug.

--- Additional comment from James W. Mills on 2014-10-24 13:47:42 EDT ---

Additional bugs around using RHEL 6.6 IPA for RHEV + RHOS LDAP authentication in the same env:

IPA: https://bugzilla.redhat.com/show_bug.cgi?id=1156595
RHOS: https://bugzilla.redhat.com/show_bug.cgi?id=1156585

--- Additional comment from Alon Bar-Lev on 2014-10-24 15:41:18 EDT ---

We should try:

GSSAPIDirContextAuthenticationStrategy.java
---
    @Override
    public void setupEnvironment(Hashtable env, String userDn, String password) throws NamingException {
        env.put(Context.SECURITY_AUTHENTICATION, GSS_API_AUTHENTICATION);
        String qopValue = configuration.getProperty("config.SASL_QOP");
        env.put("javax.security.sasl.qop", qopValue);
+       env.put("javax.security.sasl.strength", "high");
    }
---

--- Additional comment from Alon Bar-Lev on 2014-10-24 16:46:46 EDT ---

(In reply to James W. Mills from comment #3)
> Additional bugs around using RHEL 6.6 IPA for RHEV + RHOS LDAP
> authentication in the same env:
> 
> IPA: https://bugzilla.redhat.com/show_bug.cgi?id=1156595
> RHOS: https://bugzilla.redhat.com/show_bug.cgi?id=1156585

there is no need to open so many bugs for single issue, it is also possible to specify bug references as bug#1156595 or bug 1156595 for example.

--- Additional comment from Alon Bar-Lev on 2014-10-24 16:48:28 EDT ---

The actual issue is on the sasl server side[1]

"""
Having done a bit more debugging, it looks like an oddity within Cyrus-SASL's
GSSAPI plugin. If no minimum security strength factor is specified for the
acceptor, it will allow integrity and privacy protection to be negotiated,
but it will just send 0 for the maximum recv size. If I add "minssf=1" to the
sasl-secprops setting on the OpenLDAP server, the server will send a max recv
size of 65536, the Java code can successfully communicate with the server,
and all is well.
"""

Java behaves correctly, but let's see if we can workaround it at client side, or we move this to other products to handle.

[1] http://mail.openjdk.java.net/pipermail/security-dev/2013-February/006665.html

--- Additional comment from Alon Bar-Lev on 2014-10-25 12:52:30 EDT ---

Thanks for Ondra Machacek for quick setup of environment!

Workaround is to use sasl qop auth instead of auth-conf:

# engine-config -s SASL_QOP auth

Unfortunately, the engine-manage-domains utility does not respect this setting, hence the need to push a fix.

--- Additional comment from Itamar Heim on 2014-10-25 17:27:00 EDT ---

iiuc, this means RHEL 6.6 will break RHEV 3.4.z (and earlier versions) for manage domains. don't this needs a 3.4.z as well?

--- Additional comment from Alon Bar-Lev on 2014-10-25 17:31:12 EDT ---

(In reply to Itamar Heim from comment #8)
> iiuc, this means RHEL 6.6 will break RHEV 3.4.z (and earlier versions) for
> manage domains. don't this needs a 3.4.z as well?

yes, this is exactly the plan.

--- Additional comment from Alon Bar-Lev on 2014-10-25 17:38:49 EDT ---

 Itamar Heim 2014-10-25 17:33:53 EDT
Target Release: 3.5.1 → 3.4.3-1
Flags: rhevm-3.4.z? rhevm-3.5.0?

this only shows how faulty the system is...

this bug should have moved to upstream component and sched to 3.5.1.

the downstream 3.5.0 (which is invalid anyway...) should have inherited this by rebase.

the 3.4.z should have cloned if upstream 3.4.z is eof, otherwise the 3.4.z downstream would have inherited this by rebase.

we do not need pm nor qa acks to fix this in upstream.