QA:Testcase freeipav3 ad trust

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(Created page with "{{QA/Test_Case |description=Configuring and testing cross-realm trust with Active Directory. |setup= <ol> <li>Make sure your FreeIPA server is set up as in [[QA:Testcase_freei...")
 
Line 124: Line 124:
  
 
'subdomains_provider = ipa' ensures that sssd will be able to look up users in trusted domains. 'services = ..., pac' ensures that user membership information from PAC PAC (http://tools.ietf.org/html/draft-brezak-win2k-krb-authz-01) is evaluated as well.
 
'subdomains_provider = ipa' ensures that sssd will be able to look up users in trusted domains. 'services = ..., pac' ensures that user membership information from PAC PAC (http://tools.ietf.org/html/draft-brezak-win2k-krb-authz-01) is evaluated as well.
 +
 +
Restart sssd service:
 +
# systemctl restart sssd.service
  
 
=== Allow access for users from trusted domain ===
 
=== Allow access for users from trusted domain ===
Line 162: Line 165:
  
 
=== Using cross-realm trust ===
 
=== Using cross-realm trust ===
 +
==== SSH ====
 +
A GSSAPI aware Windows ssh client must be installed on the windows server. I used the putty from Quest http://rc.quest.com/topics/putty/, but recently GSSAPI support was also added to the "standard" putty http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html. If you now log on to the windows server as the test use abc and use putty to connect with GSSAPI to the FreeIPA server it should just work without asking for a password.
 +
 +
One needs to make sure home directory and default/fallback shell are defined for trusted domain users in sssd.conf, for example:
 +
 +
[domain/ipa.lan]
 +
  ...
 +
  # make trusted domain home directory as /home/<user@trusted.domain>/
 +
  subdomain_homedir = /home/%f
 +
 +
==== CIFS share ====
 +
In order to access CIFS share on FreeIPA server, one needs first to configure the share. FreeIPA Samba configuration is stored in the registry database, managed by 'net conf' command from Samba suite.
 +
 +
# net conf setparm 'share' 'comment' 'Trust test share'
 +
# net conf setparm 'share' 'read only' 'no'
 +
# net conf setparm 'share' 'valid users' 'S-1-5-21-16904141-148189700-2149043814-512'
 +
# net conf setparm 'share' 'path' '/path/to/share'
 +
 +
Make sure to change /path/to/share to proper location. Note that we are using Security Identifier of the Domain Admins group here to allow the access to the share.
  
 +
Once configuration is updated, one can mount the share from Windows machine using 'net' utility or Windows Explorer application.
 +
==== Accessing Windows resources with FreeIPA credentials ====
 +
(TODO) In order to gain access to Windows resources, users of FreeIPA realm need to be allowed appropriate privileges.
 
|results=
 
|results=
 
All the test steps should end with the specified results.
 
All the test steps should end with the specified results.
 
}}
 
}}

Revision as of 12:20, 24 September 2012

Contents

Description

Configuring and testing cross-realm trust with Active Directory.

Setup

  1. Make sure your FreeIPA server is set up as in QA:Testcase_freeipav3_installation.
  2. You have to select name for the IPA realm different from Active Directory domain name.
  3. There are two types of installation for FreeIPA:
    1. without integrated DNS setup
    2. with integrated DNS setup
    Since cross-realm trusts require working DNS autodiscovery, in both cases one need to ensure properly working DNS resolution of SRV records corresponding to Kerberos, LDAP, and other services. If DNS is handled by FreeIPA, the entries will be created when running 'ipa-adtrust-install' tool. If DNS is not managed by FreeIPA, running 'ipa-adtrust-install' with '--no-msdcs' will print all entries that need to be created. Create them at your DNS server before proceeding further after 'ipa-adtrust-install' step.

How to test

Planned configuration

Instructions below will assume following setup:

  • There is Active Directory domain, set up under name AD.LAN. Domain controller for AD.LAN server is dc.ad.lan and has IP-address DC-AD.
  • There is FreeIPA realm, set up under name IPA.LAN. FreeIPA server for the realm IPA.LAN is dc.ipa.lan and has IP-address DC-IPA.

FreeIPA realm will gain a short name used for NetBIOS communication, known as 'domain name' in SMB. Usually it is the same as leftmost component of the realm, i.e. IPA for IPA.LAN.

Installation

First, install the FreeIPA server as in QA:Testcase_freeipav3_installation.

Next, install following packages:

# yum install freeipa-server-trust-ad samba4-winbind samba4-winbind-clients

The last package, samba4-winbind-clients, is not needed for actual work. It is only needed to verify that certain operations performed by Windows client are indeed trigger proper reaction from the FreeIPA setup.

With DNS controlled by FreeIPA server

Run ipa-adtrust-install without parameters

# ipa-adtrust-install

You'll be prompted to provide needed information which will be auto-discovered based FreeIPA setup. You'll be asked to enter your admin credentials for FreeIPA server. DNS configuration will be updated to include proper SRV records expected by the Active Directory clients.

With DNS controlled by FreeIPA server

Run ipa-adtrust-install with --no-msdcs argument

# ipa-adtrust-install --no-msdcs

You'll be prompted to provide needed information which will be auto-discovered based FreeIPA setup. You'll be asked to enter your admin credentials for FreeIPA server. At the end of execution, ipa-adtrust-install will print list of SRV records that you should create at your DNS server in order to continue.

Configure DNS forwarder

Both Active Directory domain and FreeIPA realm will need to be able to find each other and discover information about each other's resources. In case there is no common uplink DNS server, appropriate domain name forwarders will need to be created from both sides.

DNS forwarder from FreeIPA side

# ipa dnszone-add ad.lan --name-server=dc.ad.lan --admin-email='hostmaster@ad.lan' --force --forwarder=DC-AD --forward-policy=only

DNS forwarder from Active Directory side

   Open Start->Administrative Tools->DNS
   make a right-click on 'Conditional Forwarders' in the left column of the window
   select 'New Conditional Forwarder...'
   add the DNS domain name of your FreeIPA domain name and the IP adresses of one or more DNS servers of your FreeIPA domain 

To test the new configuration you can try to ping your FreeIPA server again. It might be necessary to call 'ipconfig /flushdns' to removed any cached results.

Alternatively you can use command line utility dnscmd to configure the forwarder:

   Open Start -> Command Prompt
   Enter: dnscmd 127.0.0.1 /ZoneAdd ipa.lan /Forwarder DC-IPA

The command should report that zone ipa.lan was successfully added.

Verify basics

Use wbinfo utility from samba4-winbind-clients to verify that ipa-adtrust-install has set up everything right:

# wbinfo --online-status
BUILTIN : online
IPA : online

Add cross-realm trust

Add cross-realm trust to Active Directory domain:

# ipa trust-add --type=ad ad.lan --admin Administrator --password
Active directory domain adminstrator's password:
-------------------------------------------------
Added Active Directory trust for realm "ad.lan"
-------------------------------------------------
  Realm name: ad.lan
  Domain NetBIOS name: AD
  Domain Security Identifier: S-1-5-21-16904141-148189700-2149043814
  Trust direction: Two-way trust
  Trust type: Active Directory domain
  Trust status: Established and verified

Note Security Identifier of the trusted domain. Let's refer to it as AD_DOM_SID.

Restart FreeIPA KDC

For time being, FreeIPA KDC has to be restarted before it would be able to recognize new cross-realm trust.

# systemctl restart krb5kdc.service

Configure realm and domain mapping

For time being one has to manually configure krb5.conf and sssd.conf on FreeIPA server to perform cross-realm-specific operations.

Look into /etc/krb5.conf and change/add following, replacing realm names appropriately:

[libdefaults]
....
 dns_lookup_kdc = true
....

[realms]
IPA.LAN = {
....
  auth_to_local = RULE:[1:$1@$0](^.*@AD.LAN$)s/@AD.LAN/@ad.lan/
  auth_to_local = DEFAULT
}

[domain_realm]
....
.ad.lan = AD.LAN
ad.lan = AD.LAN


Look into /etc/sssd/sssd.conf and add/change following, replacing domain name ipa.lan appropriately:

[domain/ipa.lan]
...
subdomains_provider = ipa
...
[sssd]
services = nss, pam, ssh, pac

'subdomains_provider = ipa' ensures that sssd will be able to look up users in trusted domains. 'services = ..., pac' ensures that user membership information from PAC PAC (http://tools.ietf.org/html/draft-brezak-win2k-krb-authz-01) is evaluated as well.

Restart sssd service:

# systemctl restart sssd.service

Allow access for users from trusted domain

Before users from trusted domain can access resources in FreeIPA realm, they have to be explicitly mapped to FreeIPA groups. The mapping is performed in two steps:

1. Add users and groups from trusted domain to an external group in FreeIPA. External group serves as a container to reference trusted domain users and groups by their security identifiers. 1. Map external group to an existing POSIX group in FreeIPA. This POSIX group will be assigned proper group id (gid) that will be used as default group for all incoming trusted domain users mapped to this group.

Create external and POSIX groups for trusted domain users

Create external group in FreeIPA for trusted domain admins:

# ipa group-add --desc='ad.lan admins external map' ad_admins_external --external

Create POSIX group for external ad_admins_external group:

# ipa group-add --desc='ad.lan admins' ad_admins

Add users and groups from trusted domain to an external group in FreeIPA

For time being FreeIPA only accepts Security Identifiers to include as external members of external groups. One can obtain Security Identifier of the user or group from trusted domain with the help of wbinfo utility:

# wbinfo -n 'AD\Domain Admins'
S-1-5-21-16904141-148189700-2149043814-512 SID_DOM_GROUP (2)

Add security identifier of Domain Admins of the AD.LAN to the ad_admins_external group (security identifier of <AD.LAN SID>-512 is Domain Admins group):

# ipa group-add-member adadmins_external --external S-1-5-21-16904141-148189700-2149043814-512
 [member user]: 
 [member group]: 
  Group name: ad_admins_external
  Description: AD.LAN admins external map
  External member: S-1-5-21-16904141-148189700-2149043814-512
-------------------------
Number of members added 1
-------------------------

Add external group to POSIX group

Allow members of ad_admins_external group to be associated with ad_admins POSIX group:

 # ipa group-add-member ad_admins --groups ad_admins_external

Starting from this point, FreeIPA server will be able to authenticate and recognize any trusted domain user that belongs to Domain Admins group of AD.LAN domain.

Using cross-realm trust

SSH

A GSSAPI aware Windows ssh client must be installed on the windows server. I used the putty from Quest http://rc.quest.com/topics/putty/, but recently GSSAPI support was also added to the "standard" putty http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html. If you now log on to the windows server as the test use abc and use putty to connect with GSSAPI to the FreeIPA server it should just work without asking for a password.

One needs to make sure home directory and default/fallback shell are defined for trusted domain users in sssd.conf, for example:

[domain/ipa.lan]
 ...
 # make trusted domain home directory as /home/<user@trusted.domain>/
 subdomain_homedir = /home/%f

CIFS share

In order to access CIFS share on FreeIPA server, one needs first to configure the share. FreeIPA Samba configuration is stored in the registry database, managed by 'net conf' command from Samba suite.

# net conf setparm 'share' 'comment' 'Trust test share'
# net conf setparm 'share' 'read only' 'no'
# net conf setparm 'share' 'valid users' 'S-1-5-21-16904141-148189700-2149043814-512'
# net conf setparm 'share' 'path' '/path/to/share'

Make sure to change /path/to/share to proper location. Note that we are using Security Identifier of the Domain Admins group here to allow the access to the share.

Once configuration is updated, one can mount the share from Windows machine using 'net' utility or Windows Explorer application.

Accessing Windows resources with FreeIPA credentials

(TODO) In order to gain access to Windows resources, users of FreeIPA realm need to be allowed appropriate privileges.

Expected Results

All the test steps should end with the specified results.