[Users] openldap

Mon Nov 18 12:41:12 EST 2013

On 11/18/2013 06:37 PM, Jonas Israelsson wrote:
> On 18/11/13 18:26, Juan Hernandez wrote:
>> 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?
> Yes,
> 
> engine-manage-domains -action=add -domain=elementary.se 
> -provider=OpenLDAP -user=ovirt -interactive -ldapServers=ldap.elementary.se
> 

Ok. I am most certain now that engine-manage-domains ignores the DNS
query for Kerberos servers when the -ldapServers option is used, in fact
it doesn't run it. That is a bug. As a workaround you can manually fix
the generated krb5.conf file.

To verify that it is actually a bug I would appreciate if you can run
the engine-manage-domains tool and check if it is performing the DNS
query for the Kerberos server (using the DNS server log, or tcpdump). I
think that it won't do it, but need to double check.

-- 
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.