[Freeipa-users] Mapping users from AD to IPA KDC

[List dedicated to discussions about use, configuration and deployment of the IPA server.]

On ti, 06 joulu 2016, TomK wrote:
>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.
This (inability to chose Forest trust type) simply means AD DC is unable
to probe IPA DC. You said below that SMB port towards IPA DC was closed.

Also make sure to remove incorrect trust from Windows side. While we are
removing a trust object named as our NetBIOS name, it only works for the
proper trusted domain/forests, not for wrong 'realm trust' type.

>
>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.):
Firewall changes cannot affect DNS as you already had DNS port open.

>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?
You need to look at SSSD manual pages: sssd-ipa and sssd-ldap, sections
FAILOVER and SERVICE DISCOVER.

>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
This is wrong. You have effectively joined this IPA client to AD and IPA
at the same time. It should not be done this way (read
http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain
for details).

Instead, you need to identify why the trust does not work properly.
Use tcpdump to intercept the traffic between your AD DCs and IPA DCs
while establishing the trust.

You can send the trace to me off-list.



-- 
/ Alexander Bokovoy