IPv6 stack usage

Recommended way for contemporary networking applications is to only open IPv6 sockets for listening because IPv4 and IPv6 share the same port range locally. FreeIPA uses Samba as part of its Active Directory integration and Samba requires enabled IPv6 stack on the machine.

Adding ipv6.disable=1 to the kernel command line disables the whole IPv6 stack

Adding ipv6.disable_ipv6=1 will keep the IPv6 stack functional but will not assign IPv6 addresses to any of your network devices. This is recommended approach for cases when you don't use IPv6 networking.

Creating and adding to for example /etc/sysctl.d/ipv6.conf will avoid assigning IPv6 addresses to a specific network interface

Note that all we are requiring is that IPv6 stack is enabled at the kernel level and this is recommended way to develop networking applications for a long time already.

Trusts and Windows Server 2003 R2

Microsoft Windows Server 2003 extended support ended Please note, that Microsoft Windows Server 2003 extended support ended already. The trust setup procedure below will only work up to FreeIPA 4.2. FreeIPA 4.3 new installations won't have RC4 and DES support required to make the Trust working on Microsoft Windows Server 2003 (details in #4740).

As noted above, the requirement for trusts is Windows Server 2008 R2. While cross-forest trusts were added to forest functional level Windows Server 2003, there are additional requirements imposed by use of AES encryption types which require domain functional level Windows Server 2008. It is possible to establish a trust between a FreeIPA server and Windows Server 2003 R2, with limited functionality with only RC4 and DES encryption types. Next paragraph describes the actions needed in order to do this. Please note, however, that this is unsupported, highly experimental and of very limited value because of the weak encryption types for trusted domain objects which can be reasonably easy cracked with current advances in technology.

In order to establish a trust between a FreeIPA server and a Windows Server 2003 R2, you need to raise the forest functional level to Windows Server 2003. To do this, open 'Active Directory Domains and Trusts' snap-in and right-click on 'Active Directory Domains and Trusts' root in the left pane. Then select 'Raise forest functional level ...' and use 'Windows Server 2003' as the level to raise.

Make sure you perform this action before establishing a trust with the 'ipa trust-add' command. The rest of the setup is identical to that of Windows Server 2008 R2.

NOTE: NetBIOS name is the leading component of the domain name. E.g. if the domain name is ipadomain.example.com, the NetBIOS name is IPADOMAIN. NetBIOS namespace is flat, there should be no conflicts between all NetBIOS names. NetBIOS names of the IPA domain and AD domain must be different. In addtion, NetBIOS names of the IPA server and AD DC server must be different.

On IPA server

These ports must be open and available; they cannot be in use by another service or blocked by a firewall. Especially ports 88/udp, 88/tcp, 389/udp are important to keep open on IPA servers to allow AD clients to obtain cross-realm ticket granting tickets or otherwise single sign-on between AD clients and IPA services will not work.

Ports 135, 1024-1300 are needed to get DCE RPC end-point mapper to work. End-point mapper is a key component to accessLSA and SAMR pipes which are used to establish trust and access authentication and identity information in Active Directory.

Previously we recommended that you should make sure that IPA LDAP server is not reachable by AD DC by closing down TCP ports 389 and 636 for AD DC. Our current tests lead to the assumption that this is not necessary anymore. During the early development stage we tried to create a trust between IPA and AD with both IPA and AD tools. It turned out that the AD tools expect an AD like LDAP schema and layout to create a trust. Since the IPA LDAP server does not meet those requirements it is not possible to create a trust between IPA and AD with AD tools only with the 'ipa trust-add' command. By blocking the LDAP ports for the AD DC we tried to force the AD tools to fall back to other means to get the needed information with no success. But we kept the recommendation to block those ports because it was not clear at this time if AD will check the LDAP layout of a trust partner during normal operation as well. Since we have not observed those request the recommendation can be dropped.

Below are instructions on how to configure the firewall using iptables.

Firewalld

Fedora 18 introduced a new firewall manager: firewalld. However, firewalld does not yet support allowing and blocking services for specific hosts. For this reason, we recommend disabling firewalld, enabling iptables and using the sample configuration listed in section #iptables.

To disable firewalld:

# chkconfig firewalld off
# service firewalld stop

To enable iptables:

# yum install -y iptables-services
# chkconfig iptables on

Make sure iptables configuration file is located at /etc/sysconfig/iptables and contains the desired configuration, and then (re)start the iptables service:

# service iptables restart

iptables

Make sure that iptables is configured to start whenever the system is booted:

# chkconfig iptables on

iptables configuration file is /etc/sysconfig/iptables. Taking into account the rules that must be applied in order for IPA to work properly, here is a sample configuration.

Please note that the line containing "ad_ip_address" is not needed anymore (see comments above). If you still want to use it please make sure you replace ad_ip_address in the above configuration, with the IP address of AD DC.

Any changes to the iptables configuration file will require a restart of the iptables service:

# service iptables restart

DNS configuration

NOTE: Any changes to /etc/resolv.conf file will require a restart of krb5kdc, sssd and httpd services.

Both AD and IPA domains need to be visible to each other. In normal DNS configuration, no changes are required. When the testing DNS domains are not part of shared DNS tree visible to both IPA and AD, customer DNS zone forwarders can be created:

Conditional DNS forwarders

On AD DC, add conditional forwarder for IPA domain:

C:\> dnscmd 127.0.0.1 /ZoneAdd ipa_domain /Forwarder ipa_ip_address

On IPA server, add conditional forwarder for AD domain. The command in IPA version 3 and 4 are different.

When AD administrator credentials aren't available

# ipa trust-add --type=ad "ad_domain" --trust-secret

Enter the trust shared secret when prompted. At this point IPA will create two-way forest trust on IPA side. Second leg of the trust need to be created manually and validated on AD side. Following GIF sequence shows how trust with shared secret is created:

Once trust leg on AD side is established, one needs to retrieve the list of trusted forest domains from AD side. This is done using following command:

# ipa trust-fetch-domains "ad_domain"

With this command running successfuly, IPA will get information about trusted domains and will create all needed identity ranges for them.

Use "trustdomain-find" to see list of the trusted domains from a trusted forest:

# ipa trustdomain-find "ad_domain"

Edit /etc/krb5.conf

Many applications ask Kerberos library to verify that Kerberos principal can be mapped to some POSIX account. Additionally, there are some applications that perform additional check by asking the OS for the canonical name of the POSIX account returned by Kerberos library. Note that OpenSSH compares the name of principal unchanged but SSSD low-cases the realm part, thus real user name is Administrator@realm, not administrator@realm, when trying to logon with Kerberos ticket over SSH.

We have several factors in play here:

Kerberos principals use form name@REALM where REALM has to be upper case in Linux

Thus, we need to define rules for mapping Kerberos principals to system user names. If MIT Kerberos 1.12+ is in use and SSSD 1.12.1+ is in use, you can skip the rest of this section because they implement a localauth plugin that automatically does this translation and is set up by ipa-client-install.

If no SSSD support for localauth plugin is available, we need to specify auth_to_local rules that map REALM to a low-cased version. auth_to_local rules are needed to map a successfully authenticated Kerberos principal to some existing POSIX account.

For the time being, a manual configuration of /etc/krb5.conf on the IPA server is needed, to allow Kerberos authentication.

Add these two lines to /etc/krb5.conf on every machine that is going to see AD users:

Allow access for users from AD domain to protected resources

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

Add users and groups from trusted domain to an external group in IPA. External group serves as a container to reference trusted domain users and groups by their security identifiers

Map external group to an existing POSIX group in IPA. 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

Add trusted domain users to the external group

When asked for member user and member group, just leave it blank and hit Enter.

NOTE: Since arguments in above command contain backslashes, whitespace, etc, make sure to either use non-interpolation quotes (') or to escape any specials characters with a backslash (\).

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

Test cross-forest trust

Using SSH

AD users should now be able to login into IPA domain via SSH. putty SSH client for Windows (http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe) can be used to test this. When trying to connect to the IPA domain, make sure you use ad_user@ad_domain as username. Note that ad_domain must be lower-case. Also, make sure you preserve the case of the username, i.e. if username is Administrator, log in as Administrator@ad_domain, not administrator@ad_domain.

Set log level to increased debug so that packets smbd/winbindd receive get printed fully in the logs:

net conf setparm global 'log level' 100

Set log level to increased debug so that communication done by IPA when establishing trust is printed fully in the logs. Change /usr/share/ipa/smb.conf.empty:

[global]
log level = 100

Remove old /var/log/samba/log.*

Start smb and winbind services

systemctl start smb winbind

Re-add trust

ipa trust-add <forest roo> ...

If trust-add command was used with shared secret instead of explicit AD administrator credentials, after validation was performed from AD side, run

ipa trust-fetch-domains <forest root>

Package following logs and attach them to a bug or send directly to a member of FreeIPA development team who requested the logs. Please do not send logs to the public mailing lists -- logs are often quite large and would contain information specific to your AD deployment that general public shouldn't have access to. The logs we are interested in are following:

/var/log/httpd/error_log
/var/log/samba/log.*

Failures due to exhausted DNA range on replica

It may happen that the trust-add command fails with the generic ipa: ERROR: communication with CIFS server was unsuccessful message displayed in the console and Apache error log containing the following message:

This error may be caused by exhaustion of DNA range on replica caused e.g. by hastily decommissioning malfunctioning master without transferring remaining posix ID ranges to replicas. During trust setup Trusted Domain Object with allocated UID/GID must be created on FreeIPA server. Since UID/GID allocation fails, the whole trust creation process ends with error.

You may search for dnaRemainingValues attribute in cn=posix-ids,cn=dna,cn=ipa,cn=etc,$SUFFIX subtree to confirm this: