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.
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.
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
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.
On 18/11/13 18:41, Juan Hernandez wrote:
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.
Here is the whole communication between the engine and the nameserver/kdc/ldap-server during the add-domain command. I'd say it does do the query for the kerberos-server. 18:13:38.037098 IP 192.168.24.217.48417 > 192.168.24.231.53: 1+ SRV? _kerberos._tcp.elementary.se. (46) 18:13:38.037835 IP 192.168.24.231.53 > 192.168.24.217.48417: 1* 1/2/3 SRV admin.elementary.se.:88 0 0 (169) 18:13:41.230377 IP 192.168.24.217.38038 > 192.168.24.231.53: 2207+ A? ldap.elementary.se. (36) 18:13:41.230424 IP 192.168.24.217.38038 > 192.168.24.231.53: 58788+ AAAA? ldap.elementary.se. (36) 18:13:41.230716 IP 192.168.24.231.53 > 192.168.24.217.38038: 2207* 1/2/2 A 192.168.24.239 (120) 18:13:41.230834 IP 192.168.24.231.53 > 192.168.24.217.38038: 58788* 0/1/0 (82) 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 18:13:41.246949 IP 192.168.24.217.42362 > 192.168.24.239.88: Flags [.], ack 705, win 126, options [nop,nop,TS val 160790028 ecr 174749090], length 0 18:13:41.279159 IP 192.168.24.217.57156 > 192.168.24.239.389: Flags [S], seq 2210256546, win 14600, options [mss 1460,sackOK,TS val 160790060 ecr 0,nop,wscale 7], length 0 18:13:41.279218 IP 192.168.24.239.389 > 192.168.24.217.57156: Flags [S.], seq 323087650, ack 2210256547, win 14480, options [mss 1460,sackOK,TS val 174749098 ecr 160790060,nop,wscale 7], length 0 18:13:41.279627 IP 192.168.24.217.57156 > 192.168.24.239.389: Flags [.], ack 1, win 115, options [nop,nop,TS val 160790060 ecr 174749098], length 0 18:13:41.288761 IP 192.168.24.217.49767 > 192.168.24.231.53: 13267+ PTR? 239.24.168.192.in-addr.arpa. (45) 18:13:41.289162 IP 192.168.24.231.53 > 192.168.24.217.49767: 13267* 1/1/1 PTR ldap.elementary.se. (111) 18:13:41.295950 IP 192.168.24.217.42364 > 192.168.24.239.88: Flags [S], seq 2256374539, win 14600, options [mss 1460,sackOK,TS val 160790076 ecr 0,nop,wscale 7], length 0 18:13:41.296006 IP 192.168.24.239.88 > 192.168.24.217.42364: Flags [S.], seq 1178658823, ack 2256374540, win 14480, options [mss 1460,sackOK,TS val 174749103 ecr 160790076,nop,wscale 7], length 0 18:13:41.296390 IP 192.168.24.217.42364 > 192.168.24.239.88: Flags [.], ack 1, win 115, options [nop,nop,TS val 160790077 ecr 174749103], length 0 18:13:41.296440 IP 192.168.24.217.42364 > 192.168.24.239.88: Flags [P.], seq 1:646, ack 1, win 115, options [nop,nop,TS val 160790077 ecr 174749103], length 645 18:13:41.296454 IP 192.168.24.239.88 > 192.168.24.217.42364: Flags [.], ack 646, win 124, options [nop,nop,TS val 174749103 ecr 160790077], length 0 18:13:41.313368 IP 192.168.24.239.88 > 192.168.24.217.42364: Flags [P.], seq 1:626, ack 646, win 124, options [nop,nop,TS val 174749107 ecr 160790077], length 625 18:13:41.313749 IP 192.168.24.217.42364 > 192.168.24.239.88: Flags [.], ack 626, win 124, options [nop,nop,TS val 160790094 ecr 174749107], length 0 18:13:41.313766 IP 192.168.24.217.42364 > 192.168.24.239.88: Flags [F.], seq 646, ack 626, win 124, options [nop,nop,TS val 160790094 ecr 174749107], length 0 18:13:41.314773 IP 192.168.24.239.88 > 192.168.24.217.42364: Flags [F.], seq 626, ack 647, win 124, options [nop,nop,TS val 174749107 ecr 160790094], length 0 18:13:41.315070 IP 192.168.24.217.42364 > 192.168.24.239.88: Flags [.], ack 627, win 124, options [nop,nop,TS val 160790096 ecr 174749107], length 0 18:13:41.374356 IP 192.168.24.217.57156 > 192.168.24.239.389: Flags [P.], seq 1:621, ack 1, win 115, options [nop,nop,TS val 160790155 ecr 174749098], length 620 18:13:41.374425 IP 192.168.24.239.389 > 192.168.24.217.57156: Flags [.], ack 621, win 123, options [nop,nop,TS val 174749122 ecr 160790155], length 0 18:13:41.458769 IP 192.168.24.239.389 > 192.168.24.217.57156: Flags [P.], seq 1:77, ack 621, win 123, options [nop,nop,TS val 174749143 ecr 160790155], length 76 18:13:41.459284 IP 192.168.24.217.57156 > 192.168.24.239.389: Flags [.], ack 77, win 115, options [nop,nop,TS val 160790240 ecr 174749143], length 0 18:13:41.462180 IP 192.168.24.217.57156 > 192.168.24.239.389: Flags [P.], seq 621:677, ack 77, win 115, options [nop,nop,TS val 160790243 ecr 174749143], length 56 18:13:41.462237 IP 192.168.24.239.389 > 192.168.24.217.57156: Flags [.], ack 677, win 123, options [nop,nop,TS val 174749144 ecr 160790243], length 0 18:13:41.462855 IP 192.168.24.239.389 > 192.168.24.217.57156: Flags [P.], seq 77:91, ack 677, win 123, options [nop,nop,TS val 174749144 ecr 160790243], length 14 18:13:41.475422 IP 192.168.24.217.57156 > 192.168.24.239.389: Flags [F.], seq 677, ack 91, win 115, options [nop,nop,TS val 160790256 ecr 174749144], length 0 18:13:41.477538 IP 192.168.24.239.389 > 192.168.24.217.57156: Flags [F.], seq 91, ack 678, win 123, options [nop,nop,TS val 174749148 ecr 160790256], length 0 18:13:41.477853 IP 192.168.24.217.57156 > 192.168.24.239.389: Flags [.], ack 92, win 115, options [nop,nop,TS val 160790258 ecr 174749148], length 0
On 11/18/2013 06:51 PM, Jonas Israelsson wrote:
On 18/11/13 18:41, Juan Hernandez wrote:
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.
Here is the whole communication between the engine and the nameserver/kdc/ldap-server during the add-domain command. I'd say it does do the query for the kerberos-server.
18:13:38.037098 IP 192.168.24.217.48417 > 192.168.24.231.53: 1+ SRV? _kerberos._tcp.elementary.se. (46) 18:13:38.037835 IP 192.168.24.231.53 > 192.168.24.217.48417: 1* 1/2/3 SRV admin.elementary.se.:88 0 0 (169)
These ^ two lines are the query for the Kerberos server and the response. So it is doing the query, or maybe you ran the query manually with dig or ran the tool without the -ldapServers option. However I still think there is a bug and it is worth investigating it. I created this bug to track the issue: https://bugzilla.redhat.com/1031778
18:13:41.230377 IP 192.168.24.217.38038 > 192.168.24.231.53: 2207+ A? ldap.elementary.se. (36) 18:13:41.230424 IP 192.168.24.217.38038 > 192.168.24.231.53: 58788+ AAAA? ldap.elementary.se. (36) 18:13:41.230716 IP 192.168.24.231.53 > 192.168.24.217.38038: 2207* 1/2/2 A 192.168.24.239 (120) 18:13:41.230834 IP 192.168.24.231.53 > 192.168.24.217.38038: 58788* 0/1/0 (82) 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 18:13:41.246949 IP 192.168.24.217.42362 > 192.168.24.239.88: Flags [.], ack 705, win 126, options [nop,nop,TS val 160790028 ecr 174749090], length 0 18:13:41.279159 IP 192.168.24.217.57156 > 192.168.24.239.389: Flags [S], seq 2210256546, win 14600, options [mss 1460,sackOK,TS val 160790060 ecr 0,nop,wscale 7], length 0 18:13:41.279218 IP 192.168.24.239.389 > 192.168.24.217.57156: Flags [S.], seq 323087650, ack 2210256547, win 14480, options [mss 1460,sackOK,TS val 174749098 ecr 160790060,nop,wscale 7], length 0 18:13:41.279627 IP 192.168.24.217.57156 > 192.168.24.239.389: Flags [.], ack 1, win 115, options [nop,nop,TS val 160790060 ecr 174749098], length 0 18:13:41.288761 IP 192.168.24.217.49767 > 192.168.24.231.53: 13267+ PTR? 239.24.168.192.in-addr.arpa. (45) 18:13:41.289162 IP 192.168.24.231.53 > 192.168.24.217.49767: 13267* 1/1/1 PTR ldap.elementary.se. (111) 18:13:41.295950 IP 192.168.24.217.42364 > 192.168.24.239.88: Flags [S], seq 2256374539, win 14600, options [mss 1460,sackOK,TS val 160790076 ecr 0,nop,wscale 7], length 0 18:13:41.296006 IP 192.168.24.239.88 > 192.168.24.217.42364: Flags [S.], seq 1178658823, ack 2256374540, win 14480, options [mss 1460,sackOK,TS val 174749103 ecr 160790076,nop,wscale 7], length 0 18:13:41.296390 IP 192.168.24.217.42364 > 192.168.24.239.88: Flags [.], ack 1, win 115, options [nop,nop,TS val 160790077 ecr 174749103], length 0 18:13:41.296440 IP 192.168.24.217.42364 > 192.168.24.239.88: Flags [P.], seq 1:646, ack 1, win 115, options [nop,nop,TS val 160790077 ecr 174749103], length 645 18:13:41.296454 IP 192.168.24.239.88 > 192.168.24.217.42364: Flags [.], ack 646, win 124, options [nop,nop,TS val 174749103 ecr 160790077], length 0 18:13:41.313368 IP 192.168.24.239.88 > 192.168.24.217.42364: Flags [P.], seq 1:626, ack 646, win 124, options [nop,nop,TS val 174749107 ecr 160790077], length 625 18:13:41.313749 IP 192.168.24.217.42364 > 192.168.24.239.88: Flags [.], ack 626, win 124, options [nop,nop,TS val 160790094 ecr 174749107], length 0 18:13:41.313766 IP 192.168.24.217.42364 > 192.168.24.239.88: Flags [F.], seq 646, ack 626, win 124, options [nop,nop,TS val 160790094 ecr 174749107], length 0 18:13:41.314773 IP 192.168.24.239.88 > 192.168.24.217.42364: Flags [F.], seq 626, ack 647, win 124, options [nop,nop,TS val 174749107 ecr 160790094], length 0 18:13:41.315070 IP 192.168.24.217.42364 > 192.168.24.239.88: Flags [.], ack 627, win 124, options [nop,nop,TS val 160790096 ecr 174749107], length 0 18:13:41.374356 IP 192.168.24.217.57156 > 192.168.24.239.389: Flags [P.], seq 1:621, ack 1, win 115, options [nop,nop,TS val 160790155 ecr 174749098], length 620 18:13:41.374425 IP 192.168.24.239.389 > 192.168.24.217.57156: Flags [.], ack 621, win 123, options [nop,nop,TS val 174749122 ecr 160790155], length 0 18:13:41.458769 IP 192.168.24.239.389 > 192.168.24.217.57156: Flags [P.], seq 1:77, ack 621, win 123, options [nop,nop,TS val 174749143 ecr 160790155], length 76 18:13:41.459284 IP 192.168.24.217.57156 > 192.168.24.239.389: Flags [.], ack 77, win 115, options [nop,nop,TS val 160790240 ecr 174749143], length 0 18:13:41.462180 IP 192.168.24.217.57156 > 192.168.24.239.389: Flags [P.], seq 621:677, ack 77, win 115, options [nop,nop,TS val 160790243 ecr 174749143], length 56 18:13:41.462237 IP 192.168.24.239.389 > 192.168.24.217.57156: Flags [.], ack 677, win 123, options [nop,nop,TS val 174749144 ecr 160790243], length 0 18:13:41.462855 IP 192.168.24.239.389 > 192.168.24.217.57156: Flags [P.], seq 77:91, ack 677, win 123, options [nop,nop,TS val 174749144 ecr 160790243], length 14 18:13:41.475422 IP 192.168.24.217.57156 > 192.168.24.239.389: Flags [F.], seq 677, ack 91, win 115, options [nop,nop,TS val 160790256 ecr 174749144], length 0 18:13:41.477538 IP 192.168.24.239.389 > 192.168.24.217.57156: Flags [F.], seq 91, ack 678, win 123, options [nop,nop,TS val 174749148 ecr 160790256], length 0 18:13:41.477853 IP 192.168.24.217.57156 > 192.168.24.239.389: Flags [.], ack 92, win 115, options [nop,nop,TS val 160790258 ecr 174749148], length 0
-- 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.
participants (2)
-
Jonas Israelsson -
Juan Hernandez