On 12/5/2016 2:02 AM, Alexander Bokovoy wrote:
On su, 04 joulu 2016, TomK wrote:
Could not get much from logs and decided to start fresh.  When I run
this:

ipa trust-add --type=ad mds.xyz --admin Administrator --password

Trust works fine and id t...@mds.xyz returns a valid result.

However when I run the following on both masters on a fresh new setup:

ipa-adtrust-install --netbios-name=NIX -a "<SECRET>"
ipa trust-add --type=ad "mds.xyz" --trust-secret

and created a trust object in AD DC with the name of NIX and a
non-transitive trust, the above did NOT work.  I didn't get anything
by typing id t...@mds.xyz.  (I do not get an option for a Forest Trust
as the gif on this page suggests:
https://www.freeipa.org/page/Active_Directory_trust_setup .  Possibly
it's Server 2012 hence the difference in what's presented to me but
another reason is that the name I type for the trust can't resolve to
an IP for now: nix.mds.xyz . So I use NIX to match the bios name used
on the ipa-adtrust-install command above.  )
The shared secret case for one-way trust is known to be broken. When a
shared half is created on AD side first, it is marked as not yet valid
by Windows and currently we cannot perform validation of it from IPA
side. Validating it from AD side is not possible as well as we don't
provide all interfaces Windows would like to use.

And the fact you cannot see 'Forest Trust' type of the trust says also
that you have problems with reaching IPA masters from AD DC side for
probing purposes over CLDAP ping (389/UDP) and then SMB (445/TCP and
UDP).
Nothing I tried in AD Trust creation allowed me to make one with type Forest. Just realm. I recall I had a trust type of Forest but in trying various options I lost how I did that. Or perhaps I hadn't payed attention and it got created indirectly as part of another action I took. The domain functional level I'm using is Windows Server 2008. Using a lower value for testing.


I went back to the trust object in AD and set it to Transitive from
Non-transitive.  And all of a sudden I can resolve the AD ID's on the
IP Servers and all is working fine.  Great!

I could not follow the section within the online document above for
setting up forwarders.  I had to delegate nix.mds.xyz from the two AD
/ DNS Clustered Windows Server 2012 servers to the two FreeIPA servers
(idmipa01, idmipa02) .  I found that the forwarding section doesn't
quite jive well with delegation in Windows Server 2012.
Whatever you do to forward DNS in a DNS-compliant way should be enough.
The documentation typically tries to explain that there are multiple
ways to achieve this, from hackish to standards-compliant.

The remaining questions I need to ask is does the NetBIOS name used on
the ipa-adtrust-install command above have to match the AD DC Trust
object name?  Any tie's between the naming of the two?  ( Thinking no
tie in but not 100% . Seems AD expects a domain that resolves to an IP )
100% tied, this is AD requirement.

Each domain has domain name in NetBIOS, domain name in DNS, and SID. The
first two must be matching and on DNS level AD expects both to resolve
properly. It is a legacy from NT times that _all_ trusted domain objects
are named as NetBIOS$, as well as _all_ computer objects have the same
style names COMPUTER$. This is enforced on multiple levels, from SMB to
Kerberos.

What 'resolve' means here is that DNS searches for different types of
SRV records should succeed, and then CLDAP ping to the servers which are
mentioned in the
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.$DOMAIN
or _ldap._tcp.dc._msdcs.$DOMAIN should succeed too.


Also, given this setup I have:

1) The two windows servers, winad01, winad02 are both DNS, AD servers
and are clustered (NLB)

2) Have DNS delegation on nix.mds.xyz so FreeIPA servers will be
authoritative for that subdomain.

3) AD Trust objects look for a resolvable domain (ie nix.mds.xyz) and
current version of FreeIPA does not yet resolve nix.mds.xyz to any IP
No, this is not required. What required, is that trust object is
correctly set, and it involves a lot more than what you are outlining.
As you can see above, resolving nix.mds.xyz to IP is not required, but
DNS SRV records like _ldap._tcp.dc._msdcs.nix.mds.xyz should be
resolvable.

4) IPA ipa-adtrust-install only accepts NetBIOS names.
ipa-adtrust-install configures what is missing from the base setup
related to the trust to AD. NetBIOS name is missing, thus is added.


Is it at all possible to setup a non-transitive trust with all that?
( I might just not be seeing the forest through the trees  :) - Pun
Intended. )   Still new to quite a bit of this so thank you for your
patience and feedback.
Non-transitive trust is called 'external trust' in AD jargon. It can be
established to any domain in a forest. We support it from FreeIPA 4.4
with --external=true option to 'ipa trust-add'.

With non-transitive trust only users from directly trusted domain can be
seen and authenticated.



Hey Alex,

Really appreciate the detailed reply. Will need more time to retry things then I can tonight however. In the meantime, here's a few updates.

My IPA version is 4.2 right now. It came with the CentOS 7.2. Looking forward to 4.4. Not sure when you plan to include it as part of the latest CentOS base. Indeed some ports were not open (445). I've adjusted the firewall command accordingly for RHEL 7 / CentOS 7:

for KEY in $(echo "80/tcp 443/tcp 389/tcp 636/tcp 88/tcp 464/tcp 53/tcp 135/tcp 138/tcp 139/tcp 445/tcp 1024-1300/tcp 88/udp 464/udp 53/udp 123/udp 138/udp 139/udp 389/udp 445/udp"); do firewall-cmd --zone=public --permanent --add-port=$KEY; done

[root@idmipa01 ~]# firewall-cmd --zone=public --list-all
public (default)
  interfaces:
  sources:
  services: dhcpv6-client ntp ssh
ports: 443/tcp 80/tcp 464/tcp 138/tcp 88/udp 464/udp 445/tcp 88/tcp 135/tcp 123/udp 139/tcp 389/tcp 53/tcp 389/udp 1024-1300/tcp 445/udp 139/udp 138/udp 53/udp 636/tcp
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:

[root@idmipa01 ~]#

On Windows Side (The nslookup results were the same before the firewall change however.):

PS C:\Users\Administrator.WINAD01.000\desktop\netcat> .\nc -vz idmipa01 389
Warning: inverse host lookup failed for 192.168.0.44: h_errno 11004: NO_DATA
idmipa01.nix.mds.xyz [192.168.0.44] 389 (ldap) open
PS C:\Users\Administrator.WINAD01.000\desktop\netcat> .\nc -vz idmipa01 445
Warning: inverse host lookup failed for 192.168.0.44: h_errno 11004: NO_DATA
idmipa01.nix.mds.xyz [192.168.0.44] 445 (microsoft-ds): TIMEDOUT
PS C:\Users\Administrator.WINAD01.000\desktop\netcat> .\nc -vz idmipa01 445
Warning: inverse host lookup failed for 192.168.0.44: h_errno 11004: NO_DATA
idmipa01.nix.mds.xyz [192.168.0.44] 445 (microsoft-ds) open
PS C:\Users\Administrator.WINAD01.000\desktop\netcat> nslookup
Default Server:  UnKnown
Address:  ::1

> set type=srv
> _ldap._tcp.mds.xyz
Server:  UnKnown
Address:  ::1

_ldap._tcp.mds.xyz      SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = winad02.mds.xyz
_ldap._tcp.mds.xyz      SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = winad01.mds.xyz
winad02.mds.xyz internet address = 192.168.0.221
winad02.mds.xyz internet address = 192.168.0.223
winad01.mds.xyz internet address = 192.168.0.222
winad01.mds.xyz internet address = 192.168.0.224
winad01.mds.xyz internet address = 192.168.0.220
> _ldap._tcp.nix.mds.xyz
Server:  UnKnown
Address:  ::1

Non-authoritative answer:
_ldap._tcp.nix.mds.xyz  SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = idmipa01.nix.mds.xyz
_ldap._tcp.nix.mds.xyz  SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = idmipa02.nix.mds.xyz

idmipa01.nix.mds.xyz    internet address = 192.168.0.44
idmipa02.nix.mds.xyz    internet address = 192.168.0.45
> quit
PS C:\Users\Administrator.WINAD01.000\desktop\netcat>

[root@idmipa01 ~]# dig SRV _ldap._tcp.mds.xyz

; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.4 <<>> SRV _ldap._tcp.mds.xyz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61590
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_ldap._tcp.mds.xyz.            IN      SRV

;; ANSWER SECTION:
_ldap._tcp.mds.xyz.     600     IN      SRV     0 100 389 winad01.mds.xyz.
_ldap._tcp.mds.xyz.     600     IN      SRV     0 100 389 winad02.mds.xyz.

;; AUTHORITY SECTION:
xyz.                    75802   IN      NS      z.nic.xyz.
xyz.                    75802   IN      NS      generationxyz.nic.xyz.
xyz.                    75802   IN      NS      y.nic.xyz.
xyz.                    75802   IN      NS      x.nic.xyz.

;; ADDITIONAL SECTION:
y.nic.xyz.              162201  IN      A       185.24.64.42
y.nic.xyz.              162201  IN      AAAA    2a04:2b00:13cc::1:42
z.nic.xyz.              162201  IN      A       212.18.248.42
z.nic.xyz.              162201  IN      AAAA    2a04:2b00:13ee::42
x.nic.xyz.              162201  IN      A       194.169.218.42
x.nic.xyz.              162201  IN      AAAA    2001:67c:13cc::1:42
generationxyz.nic.xyz.  162201  IN      A       212.18.249.42
generationxyz.nic.xyz.  162201  IN      AAAA    2a04:2b00:13ff::42

;; Query time: 331 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Dec 06 00:11:31 EST 2016
;; MSG SIZE  rcvd: 373

[root@idmipa01 ~]# dig SRV _ldap._tcp.nix.mds.xyz

; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.4 <<>> SRV _ldap._tcp.nix.mds.xyz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1651
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_ldap._tcp.nix.mds.xyz.                IN      SRV

;; ANSWER SECTION:
_ldap._tcp.nix.mds.xyz. 86400 IN SRV 0 100 389 idmipa01.nix.mds.xyz. _ldap._tcp.nix.mds.xyz. 86400 IN SRV 0 100 389 idmipa02.nix.mds.xyz.

;; AUTHORITY SECTION:
nix.mds.xyz.            86400   IN      NS      idmipa02.nix.mds.xyz.
nix.mds.xyz.            86400   IN      NS      idmipa01.nix.mds.xyz.

;; ADDITIONAL SECTION:
idmipa01.nix.mds.xyz.   1200    IN      A       192.168.0.44
idmipa02.nix.mds.xyz.   1200    IN      A       192.168.0.45

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Dec 06 00:11:48 EST 2016
;; MSG SIZE  rcvd: 191

[root@idmipa01 ~]#


On the AD side, I added the SRV records for the second AD DC, manually, since earlier there were no results printed on the AD DC command line for the second AD DC, when I typed the command _ldap._tcp.mds.xyz.

One additional question I had with the setup is in regards to the failover. I see the ipa_server entry in /etc/sssd/sssd.conf pointing to two of the master IPA nodes. Where can I find the additional settings that control priority of the listed server or order they are checked?


[root@ipaclient01 ~]# cat /etc/sssd/sssd.conf
[domain/nix.mds.xyz]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = nix.mds.xyz
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = ipaclient01.nix.mds.xyz
chpass_provider = ipa
ipa_server = idmipa01.nix.mds.xyz, idmipa02.nix.mds.xyz
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
debug_level = 9
services = nss, sudo, pam, ssh
config_file_version = 2

domains = nix.mds.xyz, mds.xyz

[nss]
debug_level = 9
homedir_substring = /home

[pam]
debug_level = 9

[sudo]
debug_level = 9

[autofs]

[ssh]
debug_level = 9

[pac]
debug_level = 9

[ifp]


[domain/mds.xyz]
ad_domain = mds.xyz
krb5_realm = MDS.XYZ
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = ad
[root@ipaclient01 ~]#


What I ran to get the above is:

1) ipa-client-install --force-join -p admin -w "<HUSH!>" --fixed-primary --server=idmipa01.nix.mds.xyz --server=idmipa02.nix.mds.xyz --domain=nix.mds.xyz --realm=NIX.MDS.XYZ -U
2) realm join mds.xyz

Then I could login using MDS.XYZ\t...@ipaclient01.nix.mds.xyz Bit ugly but works for now till I get a better login ID worked out using /etc/krb5.conf settings on the master. Currently it's the default:

  auth_to_local = RULE:[1:$1@$0](^.*@MDS.XYZ$)s/@MDS.XYZ/@mds.xyz/
  auth_to_local = DEFAULT


The kerberos / ldap records do resolve as expected:


[root@idmipa01 ~]# nslookup
> _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs
Server:         127.0.0.1
Address:        127.0.0.1#53

*** Can't find _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs: No answer
> set type=srv
> _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs
Server:         127.0.0.1
Address:        127.0.0.1#53

_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.nix.mds.xyz service = 0 100 88 idmipa02.nix.mds.xyz. _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.nix.mds.xyz service = 0 100 88 idmipa01.nix.mds.xyz.
> _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs
Server:         127.0.0.1
Address:        127.0.0.1#53

_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.nix.mds.xyz service = 0 100 389 idmipa01.nix.mds.xyz. _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.nix.mds.xyz service = 0 100 389 idmipa02.nix.mds.xyz.
> quit
Server:         127.0.0.1
Address:        127.0.0.1#53

** server can't find quit: NXDOMAIN
> exit

[root@idmipa01 ~]#



--
Cheers,
Tom K.
-------------------------------------------------------------------------------------

Living on earth is expensive, but it includes a free trip around the sun.

--
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
  • ... TomK
    • ... Sumit Bose
      • ... TomK
        • ... TomK
          • ... TomK
            • ... Alexander Bokovoy
              • ... TomK
                • ... List dedicated to discussions about use, configuration and deployment of the IPA server.
                • ... List dedicated to discussions about use, configuration and deployment of the IPA server.
                • ... TomK
                • ... TomK

Reply via email to