[Users] engine-manage-domains fails when re-adding a domain

Fri Nov 15 18:47:14 UTC 2013

Juan Hernandez <jhernand at redhat.com> wrote:
>
>On 11/13/2013 10:11 PM, Junk wrote:
>> Hi I was having odd issues with my IPA domain so rather than
>> troubleshoot it properly I thought it would be a good idea to remove
>it
>> and then add it again.
>> 
>> I removed it with 
>> engine-manage-domains -action=delete -domain=clarkconnect.lan
>> 
>> and when I try to add it with 
>> engine-manage-domains -action=add -domain=clarkconnect.lan
>-user=admin
>> -provider=IPA -interactive
>> 
>> which worked fine the first time I get
>> 
>> 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)
>> 	at sun.security.jgss.krb5.Krb5Context.wrap(Krb5Context.java:861)
>> 	at sun.security.jgss.GSSContextImpl.wrap(GSSContextImpl.java:385)
>> 	at
>com.sun.security.sasl.gsskerb.GssKrb5Base.wrap(GssKrb5Base.java:104)
>> 	at
>>
>com.sun.jndi.ldap.sasl.SaslOutputStream.write(SaslOutputStream.java:89)
>> 	at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:430)
>> 	at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:555)
>> 	at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1985)
>> 	at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1847)
>> 	at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1772)
>> 	at
>>
>com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:386)
>> 	at
>>
>com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:356)
>> 	at
>>
>com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:339)
>> 	at
>>
>javax.naming.directory.InitialDirContext.search(InitialDirContext.java:267)
>> 	at
>org.ovirt.engine.core.ldap.RootDSEData.<init>(RootDSEData.java:52)
>> 	at
>>
>org.ovirt.engine.core.utils.kerberos.JndiAction.getDomainDN(JndiAction.java:257)
>> 	at
>>
>org.ovirt.engine.core.utils.kerberos.JndiAction.run(JndiAction.java:87)
>> 	at java.security.AccessController.doPrivileged(Native Method)
>> 	at javax.security.auth.Subject.doAs(Subject.java:356)
>> 	at
>>
>org.ovirt.engine.core.utils.kerberos.KerberosConfigCheck.promptSuccessfulAuthentication(KerberosConfigCheck.java:174)
>> 	at
>>
>org.ovirt.engine.core.utils.kerberos.KerberosConfigCheck.validateKerberosInstallation(KerberosConfigCheck.java:150)
>> 	at
>>
>org.ovirt.engine.core.utils.kerberos.KerberosConfigCheck.checkInstallation(KerberosConfigCheck.java:135)
>> 	at
>>
>org.ovirt.engine.core.domains.ManageDomains.checkKerberosConfiguration(ManageDomains.java:746)
>> 	at
>>
>org.ovirt.engine.core.domains.ManageDomains.testConfiguration(ManageDomains.java:917)
>> 	at
>>
>org.ovirt.engine.core.domains.ManageDomains.addDomain(ManageDomains.java:539)
>> 	at
>>
>org.ovirt.engine.core.domains.ManageDomains.runCommand(ManageDomains.java:311)
>> 	at
>>
>org.ovirt.engine.core.domains.ManageDomains.main(ManageDomains.java:206)
>> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at
>>
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> 	at
>>
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> 	at java.lang.reflect.Method.invoke(Method.java:606)
>> 	at org.jboss.modules.Module.run(Module.java:260)
>> 	at org.jboss.modules.Main.main(Main.java:291)
>> Failure while testing domain %1$s. Details: %2$s: One of the
>parameters
>> for this error is null and no default message to show
>> 
>> 
>> in the engine-manage-domains.log I get
>> 
>> 2013-11-13 20:53:41,318 INFO
>> [org.ovirt.engine.core.domains.ManageDomains] Creating kerberos
>> configuration for domain(s): clarkconnect.lan
>> 2013-11-13 20:53:41,525 INFO
>> [org.ovirt.engine.core.domains.ManageDomains] Successfully created
>> kerberos configuration for domain(s): clarkconnect.lan
>> 2013-11-13 20:53:41,526 INFO
>> [org.ovirt.engine.core.domains.ManageDomains] Testing kerberos
>> configuration for domain: clarkconnect.lan
>> 2013-11-13 20:53:48,718 ERROR
>> [org.ovirt.engine.core.domains.ManageDomains] Failure while testing
>> domain %1$s. Details: %2$s: One of the parameters for this error is
>null
>> and no default message to show
>> 
>> any ideas?
>> 
>> Junk
>> 
>
>We have seen a similar issue with OpenLDAP that required to set the
>minimum security strength factor (SSF) to 1 instead of the default 0.
>This default triggers a bug in the Java virtual machine Kerberos
>support.
>
>IPA uses the 389 directory server, and it also has the possibility to
>configure this, as described here:
>
>http://directory.fedoraproject.org/wiki/Minimum_SSF_Setting
>
>To check that you can run a query like this in your IPA installation:
>
># kinit admin
># ldapsearch \
>-H ldap://your_ipa_server \
>-Y GSSAPI \
>-LLL \
>-b 'cn=config' \
>-s base \
>nsslapd-minssf
>
>The output will probably be like this:
>
>dn: cn=config
>nsslapd-minssf: 0
>
>The important thing there is the value 0. You can try to change it to
>1,
>via LDAP or modifying directly the file
>/etc/dirsrv/slapd-YOUR-REALM/dse.ldif. Do this with the directory
>server
>stopped, and remember how to revert it in case things fail.
>
>Let us know if this helps.
>
>By the way, for those interested in how to change this in OpenLDAP, it
>requires something like this:
>
># cat > fixssf.ldif <<'.'
>dn: cn=config
>replace: olcSaslSecProps
>olcSaslSecProps: noanonymous,noplain,minssf=1
>-
>.
>
># ldapmodify -H ldapi:/// -Y EXTERNAL -f fixssf.ldif
>
>-- 
>Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
>3ºD, 28016 Madrid, Spain
>Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat
>S.L.

That did the trick. I edited the file as I had no hope of getting an ldapmodify command going on my own. That's why I installed IPA in the first place. :)
-- 
Junk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20131115/43c7dac9/attachment-0001.html>