[Freeipa-users] Mapping users from AD to IPA KDC
TomK
tk at mdevsys.com
Tue Dec 6 06:35:19 UTC 2016
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 tom at 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 tom at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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\tom at 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 at 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 at idmipa01 ~]#
--
Cheers,
Tom K.
-------------------------------------------------------------------------------------
Living on earth is expensive, but it includes a free trip around the sun.
More information about the Freeipa-users
mailing list