Re: [Freeipa-users] Trust with Active Directory fails
Well, that's a surprise! Since the ipv6 module is running, I had assumed that IPv6 is enabled: # lsmod | grep ipv6 ipv6 334932 0 I'll look into getting IPv6 enabled. (This is a RHEL6 server, which uses SysV init instead of systemd.) Thanks for your help. David Guertin Information Technology Services Middlebury College 700 Exchange St. Middlebury, VT 05753 (802)443-3143 From: Alexander Bokovoy aboko...@redhat.com Sent: Tuesday, February 10, 2015 2:51 AM To: Guertin, David S. Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] Trust with Active Directory fails On Mon, 09 Feb 2015, Guertin, David S. wrote: Can you send me (off-list) logs as described in http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Debugging_tr ust Alexander, Here are the log files you requested. Thanks, you have IPv6 protocol family disabled in your kernel. Samba opens its sockets using IPv6-enabled functions because system library is recommending that (see man page for IPv6). [2015/02/09 13:29:59.577360, 0, pid=3012, effective(0, 0), real(0, 0)] ../source3/lib/util_sock.c:423(open_socket_in) open_socket_in(): socket() call failed: Address family not supported by protocol [2015/02/09 13:29:59.577485, 0, pid=3012, effective(0, 0), real(0, 0)] ../source3/rpc_server/rpc_server.c:636(create_tcpip_socket) Failed to create socket on port 135! [2015/02/09 13:29:59.577523, 0, pid=3012, effective(0, 0), real(0, 0)] ../source3/rpc_server/epmd.c:202(start_epmd) Failed to open epmd tcpip sockets! As result, we are unable to proceed with the connection to local portmapper and cannot operate on the IPA's half of the trust. See http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#IPv6_stack_usage for details. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Trust with Active Directory fails
For the record, here's the solution I came up with for RHEL6 (and presumably other SysV init-based systems): Its Linux kernel is 2.6, which does have IPv6 enabled. The ipv6 module is loaded. I had looked at those and assumed that everything was OK, but these two are not enough. I needed to edit /etc/modprobe/ipv6.conf and change ipv6 disable=1 to ipv6 disable=0. Now it works. David Guertin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Trust with Active Directory fails
For Active Directory cross-forest trusts to work, we need following records to be in place: _ldap._tcp.DOMAIN _kerberos._udp.DOMAIN _kerberos._tcp.DOMAIN _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.DOMAIN _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.DOMAIN _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.DOMAIN _ldap._tcp.dc._msdcs.DOMAIN _kerberos._udp.dc._msdcs.DOMAIN _kerberos._tcp.dc._msdcs.DOMAIN I've checked with nslookup, and for the IPA subdomain csns.example.com, all the records are in place. For the parent example.com domain, though, the following four records are not found: _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.example.com _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.example.com _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.example.com _kerberos._udp.dc._msdcs.example.com Do these need to be manually added to our DNS records? I've never had to manually add an SRV record before. If it matters, we are not using our domain controllers as our DNS servers -- we have separate, dedicated DNS servers in our environment. Thanks, David Guertin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Trust with Active Directory fails
On Mon, 09 Feb 2015, Guertin, David S. wrote: For Active Directory cross-forest trusts to work, we need following records to be in place: _ldap._tcp.DOMAIN _kerberos._udp.DOMAIN _kerberos._tcp.DOMAIN _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.DOMAIN _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.DOMAIN _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.DOMAIN _ldap._tcp.dc._msdcs.DOMAIN _kerberos._udp.dc._msdcs.DOMAIN _kerberos._tcp.dc._msdcs.DOMAIN I've checked with nslookup, and for the IPA subdomain csns.example.com, all the records are in place. For the parent example.com domain, though, the following four records are not found: _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.example.com _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.example.com _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.example.com _kerberos._udp.dc._msdcs.example.com Do these need to be manually added to our DNS records? I've never had to manually add an SRV record before. If it matters, we are not using our domain controllers as our DNS servers -- we have separate, dedicated DNS servers in our environment. Can you send me (off-list) logs as described in http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Debugging_trust -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Trust with Active Directory fails
On Thu, 05 Feb 2015, Guertin, David S. wrote: I'm trying to set up a trust between IPA and Active Directory, and it keeps failing. The problem is the same as this one (https://www.redhat.com/archives/freeipa-users/2014-April/msg00039.html), but the solution is not. In that case, it was solved by enabling IPv6 in the kernel, and in this case IPv6 is already enabled. Here's what happens: # ipa trust-add --type=ad example.com ipa: ERROR: Cannot find specified domain or server name It looks like a DNS problem, and all the suggestions I've seen point to DNS, but from everything I can see, DNS appears to be working. I have the IPA domain set up as a subdomain (csns.example.com) of the AD domain (example.com). Our AD domain controllers are NOT set up as DNS servers -- we have external, independent DNS servers for that. (Could that be part of the problem?) I am running bind on the IPA server (which is running RHEL6), because all the documentation was written that way. It is set up as a delegation subdomain of our main domain. We don't require DNS to be tied to any specific party (IPA or AD), all we require is that all proper service records (SRV) are in place. For Active Directory cross-forest trusts to work, we need following records to be in place: _ldap._tcp.DOMAIN _kerberos._udp.DOMAIN _kerberos._tcp.DOMAIN _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.DOMAIN _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.DOMAIN _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.DOMAIN _ldap._tcp.dc._msdcs.DOMAIN _kerberos._udp.dc._msdcs.DOMAIN _kerberos._tcp.dc._msdcs.DOMAIN When you run ipa-adtrust-install, it will generate these records for IPA domain but when we perform trust, Samba libraries resolve these in AD domain too. Make sure they are properly configured. From the IPA server, dig finds the AD domain controllers: # dig SRV _ldap._tcp.example.com ; DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.1 SRV _ldap._tcp.example.com ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 8858 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 13, ADDITIONAL: 0 ;; QUESTION SECTION: ;_ldap._tcp.example.com. IN SRV ;; ANSWER SECTION: _ldap._tcp.example.com. 600IN SRV0 100 389 dc1.example.com. _ldap._tcp.example.com. 600IN SRV0 100 389 dc2.example.com. _ldap._tcp.example.com. 600IN SRV0 100 389 dc3.example.com. _ldap._tcp.example.com. 600IN SRV0 100 389 dc4.example.com. _ldap._tcp.example.com. 600IN SRV0 100 389 dc5.example.com. _ldap._tcp.example.com. 600IN SRV0 100 389 dc6.example.com. ;; AUTHORITY SECTION: . 407417 IN NS b.root-servers.net. . 407417 IN NS a.root-servers.net. . 407417 IN NS h.root-servers.net. . 407417 IN NS f.root-servers.net. . 407417 IN NS m.root-servers.net. . 407417 IN NS k.root-servers.net. . 407417 IN NS l.root-servers.net. . 407417 IN NS g.root-servers.net. . 407417 IN NS e.root-servers.net. . 407417 IN NS j.root-servers.net. . 407417 IN NS i.root-servers.net. . 407417 IN NS d.root-servers.net. . 407417 IN NS c.root-servers.net. ;; Query time: 2 msec ;; SERVER: 140.233.1.7#53(140.233.1.7) ;; WHEN: Thu Feb 5 16:38:22 2015 ;; MSG SIZE rcvd: 503 And, with nslookup, I can do name lookups on the domain controllers and the DNS servers, and they all find the appropriate IP address. It all works the other way, too. From the domain controllers I can do nslookup on the IPA server. In fact, every nslookup or ping command I do on any hostname from anyway all works -- it's only the ipa trust-add command that's failing. I've set log level to 100 in /usr/share/ipa/smb.conf.empty, and here's the output in /var/log/httpd/error_log: lpcfg_load: refreshing parameters from /usr/share/ipa/smb.conf.empty params.c:pm_process() - Processing configuration file /usr/share/ipa/smb.conf.empty Processing section [global] INFO: Current debug levels: all: 100 tdb: 100 printdrivers: 100 lanman: 100 smb: 100 rpc_parse: 100 rpc_srv: 100 rpc_cli:
[Freeipa-users] Trust with Active Directory fails
I'm trying to set up a trust between IPA and Active Directory, and it keeps failing. The problem is the same as this one (https://www.redhat.com/archives/freeipa-users/2014-April/msg00039.html), but the solution is not. In that case, it was solved by enabling IPv6 in the kernel, and in this case IPv6 is already enabled. Here's what happens: # ipa trust-add --type=ad example.com ipa: ERROR: Cannot find specified domain or server name It looks like a DNS problem, and all the suggestions I've seen point to DNS, but from everything I can see, DNS appears to be working. I have the IPA domain set up as a subdomain (csns.example.com) of the AD domain (example.com). Our AD domain controllers are NOT set up as DNS servers -- we have external, independent DNS servers for that. (Could that be part of the problem?) I am running bind on the IPA server (which is running RHEL6), because all the documentation was written that way. It is set up as a delegation subdomain of our main domain. From the IPA server, dig finds the AD domain controllers: # dig SRV _ldap._tcp.example.com ; DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.1 SRV _ldap._tcp.example.com ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 8858 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 13, ADDITIONAL: 0 ;; QUESTION SECTION: ;_ldap._tcp.example.com. IN SRV ;; ANSWER SECTION: _ldap._tcp.example.com. 600IN SRV0 100 389 dc1.example.com. _ldap._tcp.example.com. 600IN SRV0 100 389 dc2.example.com. _ldap._tcp.example.com. 600IN SRV0 100 389 dc3.example.com. _ldap._tcp.example.com. 600IN SRV0 100 389 dc4.example.com. _ldap._tcp.example.com. 600IN SRV0 100 389 dc5.example.com. _ldap._tcp.example.com. 600IN SRV0 100 389 dc6.example.com. ;; AUTHORITY SECTION: . 407417 IN NS b.root-servers.net. . 407417 IN NS a.root-servers.net. . 407417 IN NS h.root-servers.net. . 407417 IN NS f.root-servers.net. . 407417 IN NS m.root-servers.net. . 407417 IN NS k.root-servers.net. . 407417 IN NS l.root-servers.net. . 407417 IN NS g.root-servers.net. . 407417 IN NS e.root-servers.net. . 407417 IN NS j.root-servers.net. . 407417 IN NS i.root-servers.net. . 407417 IN NS d.root-servers.net. . 407417 IN NS c.root-servers.net. ;; Query time: 2 msec ;; SERVER: 140.233.1.7#53(140.233.1.7) ;; WHEN: Thu Feb 5 16:38:22 2015 ;; MSG SIZE rcvd: 503 And, with nslookup, I can do name lookups on the domain controllers and the DNS servers, and they all find the appropriate IP address. It all works the other way, too. From the domain controllers I can do nslookup on the IPA server. In fact, every nslookup or ping command I do on any hostname from anyway all works -- it's only the ipa trust-add command that's failing. I've set log level to 100 in /usr/share/ipa/smb.conf.empty, and here's the output in /var/log/httpd/error_log: lpcfg_load: refreshing parameters from /usr/share/ipa/smb.conf.empty params.c:pm_process() - Processing configuration file /usr/share/ipa/smb.conf.empty Processing section [global] INFO: Current debug levels: all: 100 tdb: 100 printdrivers: 100 lanman: 100 smb: 100 rpc_parse: 100 rpc_srv: 100 rpc_cli: 100 passdb: 100 sam: 100 auth: 100 winbind: 100 vfs: 100 idmap: 100 quota: 100 acls: 100 locking: 100 msdfs: 100 dmapi: 100 registry: 100 pm_process() returned Yes Using binding ncacn_np:civet.csns.example.com[,] tevent: Added timed event dcerpc_connect_timeout_handler: 0x7f22f41eeb60 tevent: Added timed event composite_trigger: 0x7f22f403d270 tevent: Added timed event composite_trigger: 0x7f22f41efdc0 tevent: Running timer event 0x7f22f403d270 composite_trigger tevent: Destroying timer event 0x7f22f41efdc0 composite_trigger Mapped to DCERPC endpoint \pipe\lsarpc added interface eth0 ip=140.233.1.7 bcast=140.233.1.255 netmask=255.255.255.0 added interface eth0 ip=140.233.1.7 bcast=140.233.1.255 netmask=255.255.255.0 tevent: Ending timer event 0x7f22f403d270
