[Users] openldap

Mon Nov 18 17:21:38 UTC 2013

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.