Re: [Users] openldap

On 18/11/13 17:24, Juan Hernandez wrote: > On 11/18/2013 12:17 PM, Jonas Israelsson wrote: >> On 17/10/13 17:22, Juan Hernandez wrote: >>> On 10/17/2013 05:15 PM, Itamar Heim wrote: >>>> On 10/17/2013 09:57 AM, Jonas Israelsson wrote: >>>>> I saw that openldap is now listed as a provider when invoking >>>>> engine-manage-domains. I'm eager to find more information about this. >>>>> Does anyone know if there is any updated documentation floating around >>>>> somewhere ? >>>>> >>>>> Found this:http://www.ovirt.org/LDAP_Quick_Start >>>>> >>>>> But the article seem only half-finished. >>>>> >>>>> Rgds Jonas >>>>> >>>> this may help you. >>>> https://bugzilla.redhat.com/show_bug.cgi?id=967327#c4 >>>> https://bugzilla.redhat.com/show_bug.cgi?id=967327#c5 >>>> >>>> help finishing the wiki would be great... >>>> >>>> thanks, >>>> Itamar >>>> >>> I am attaching slightly updated notes on how to configure OpenLDAP and >>> Kerberos for both Fedora and RHEL/CentOS. >>> > I just updated the wiki with the latest version of the instructions that > I use. I think they work. Any enhancement is welcome. > >> Anyone knows if ovirt is able to handle that the kdc and directory >> service are running on separate hosts ? In my environment this is the >> case where the kdc is located at a service with it's own name/IP >> (admin.elementary.se), and the directory-service on ldap.elementary.se. >> Even though I see both names are resolved by a name server lookup a >> network sniffer trace shows that later (ldap.elementary.se) used for >> both kerberos and ldap access. >> > By default oVirt uses the Kerberos and LDAP servers that are provided by > DNS. Can you please check what is the result of the following DNS query? > > # dig -t SRV _kerberos._tcp.elementary.se All DNS querys gets the correct answer (both forward and reverse) Engine -- 192.168.24.217 -- dashboard.elementary.se LDAP-Server -- 192.168.24.239 -- ldap.elementary.se KDC -- 192.168.24.240 -- admin.elementary.se dig -t SRV _kerberos._tcp.elementary.se ; <<>> DiG 9.9.3-rpz2+rl.156.01-P2 <<>> -t SRV _kerberos._tcp.elementary.se ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19187 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;_kerberos._tcp.elementary.se. IN SRV ;; ANSWER SECTION: _kerberos._tcp.elementary.se. 3600 IN SRV 0 0 88 admin.elementary.se. ;; AUTHORITY SECTION: elementary.se. 3600 IN NS ns2.elementary.se. elementary.se. 3600 IN NS ns1.elementary.se. ;; ADDITIONAL SECTION: admin.elementary.se. 3600 IN A 192.168.24.240 ns1.elementary.se. 3600 IN A 192.168.24.231 ns2.elementary.se. 3600 IN A 192.168.24.232 ;; Query time: 0 msec ;; SERVER: 192.168.24.231#53(192.168.24.231) ;; WHEN: Mon Nov 18 18:05:05 CET 2013 ;; MSG SIZE rcvd: 180 Still... 18:13:41.232154 IP 192.168.24.217.42362 > 192.168.24.239.88: Flags [S], seq 3592225170, win 14600, options [mss 1460,sackOK,TS val 160790012 ecr 0,nop,wscale 7], length 0 18:13:41.232238 IP 192.168.24.239.88 > 192.168.24.217.42362: Flags [S.], seq 2526310478, ack 3592225171, win 14480, options [mss 1460,sackOK,TS val 174749087 ecr 160790012,nop,wscale 7], length 0 18:13:41.232739 IP 192.168.24.217.42362 > 192.168.24.239.88: Flags [.], ack 1, win 115, options [nop,nop,TS val 160790013 ecr 174749087], length 0 18:13:41.232787 IP 192.168.24.217.42362 > 192.168.24.239.88: Flags [P.], seq 1:141, ack 1, win 115, options [nop,nop,TS val 160790013 ecr 174749087], length 140 18:13:41.232804 IP 192.168.24.239.88 > 192.168.24.217.42362: Flags [.], ack 141, win 122, options [nop,nop,TS val 174749087 ecr 160790013], length 0 18:13:41.245137 IP 192.168.24.239.88 > 192.168.24.217.42362: Flags [P.], seq 1:704, ack 141, win 122, options [nop,nop,TS val 174749090 ecr 160790013], length 703 18:13:41.245517 IP 192.168.24.217.42362 > 192.168.24.239.88: Flags [.], ack 704, win 126, options [nop,nop,TS val 160790026 ecr 174749090], length 0 18:13:41.245578 IP 192.168.24.217.42362 > 192.168.24.239.88: Flags [F.], seq 141, ack 704, win 126, options [nop,nop,TS val 160790026 ecr 174749090], length 0 18:13:41.246606 IP 192.168.24.239.88 > 192.168.24.217.42362: Flags [F.], seq 704, ack 142, win 122, options [nop,nop,TS val 174749090 ecr 160790026], length 0

>> wouFurthermore this (incorrect) configuration file is created >> >> [libdefaults] >> >> default_realm = ELEMENTARY.SE >> dns_lookup_realm = false >> dns_lookup_kdc = false >> ticket_lifetime = 24h >> renew_lifetime = 7d >> forwardable = no >> default_tkt_enctypes = arcfour-hmac-md5 >> udp_preference_limit = 1 >> >> [realms] >> ELEMENTARY.SE = { >> kdc = ldap.elementary.se >> } >> >> >> [domain_realm] >> elementary.se = ELEMENTARY.SE >> >> >> In my lab both these services are actually placed on the same physical >> server and since the kdc binds to all local interfaces ovirt actually >> does reach the kdc via the incorrect name, this is however not the case >> later in production. >> > This file is generated from the above mentioned DNS queries. Please let > us know what is the content of your SRV DNS records. > >> When trying to add the domain it crashes with the following stack trace >> >> 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 >> >> And this gets written to the log >> >> 2013-11-18 10:22:12,479 INFO >> [org.ovirt.engine.core.domains.ManageDomains] Creating kerberos >> configuration for domain(s): elementary.se >> 2013-11-18 10:22:12,493 INFO >> [org.ovirt.engine.core.domains.ManageDomains] Successfully created >> kerberos configuration for domain(s): elementary.se >> 2013-11-18 10:22:12,493 INFO >> [org.ovirt.engine.core.domains.ManageDomains] Testing kerberos >> configuration for domain: elementary.se >> 2013-11-18 10:22:12,569 ERROR >> [org.ovirt.engine.core.utils.kerberos.KerberosConfigCheck] Error: >> exception message: Checksum failed >> 2013-11-18 10:22:12,571 ERROR >> [org.ovirt.engine.core.domains.ManageDomains] Failure while testing >> domain elementary.se. Details: Kerberos error. Please check log for >> further details. >> >> Could this checksum error be a result of the incorrect name being used ? >> > I don't think so. This is a known problem with the Kerberos > implementation in the Java virtual machine. It generates this error when > the SASL minssf configuration parameter is 0. You should be able to > change this OpenLDAP setting as follows: > > # cat > fixssf.ldif <<'.' > dn: cn=config > replace: olcSaslSecProps > olcSaslSecProps: noanonymous,noplain,minssf=1 > - > . > # ldapmodify -H ldapi:/// -Y EXTERNAL -f fixssf.ldif > > OK Great, I'll have a look.