[Users] openldap
Juan Hernandez
jhernand at redhat.com
Mon Nov 18 17:26:04 UTC 2013
On 11/18/2013 06:21 PM, Jonas Israelsson wrote:
>
>
> 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
>
>
>
Your SRV records look correct. We may have a bug here. What
"engine-manage-domains" command line are you exactly using? Are you
using the "-ldapServers" option?
>>> 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.
>
>
>
>
--
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.
More information about the Users
mailing list