From Fedora Project Wiki
(update to associated release criteria as server roles are gone)
 
(9 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{Template:Associated_release_criterion|Basic|freeipa-server-requirements}}
{{Template:Associated_release_criterion|Basic|remote-authentication}}
{{QA/Test_Case
{{QA/Test_Case
|description=Join the current machine to an Active Directory domain using sssd as an AD client. Domain accounts are available on the local machine once this is done.
|description=This test case ensures that you can enrol a machine as a client in an Active Directory or FreeIPA domain with the {{command|realm}} command, using sssd as an AD or FreeIPA client.
|setup=
|setup=
# [[Features/ActiveDirectory/TestBed|Verify that your Active Directory domain access works]]. If you don't have an Active Directory domain, you can [[Features/ActiveDirectory/TestBed|set one up]].
{{Domain server setup}}
# You need a domain account, either a user or administrator. It's useful to test with both.
{{Domain_client_enrol_prep}}
# '''Your machine must have a configured host name. Do not proceed if you host name is <code>localhost</code> or similar.'''
{{Domain_client_realmd_prep}}
#: <pre>$ hostname</pre>
# The client must be capable of resolving the FreeIPA or Active Directory servers by FQDN. The easiest method of accomplishing this is to use Cockpit to modify the default DNS server address to be the IP address of the domain controller. If the domain controller is not running a DNS server, the alternative is to modify /etc/hosts on the client to contain the appropriate IP address for the domain controller FQDN.
# Make sure you have [https://admin.fedoraproject.org/updates/FEDORA-2012-16542/realmd-0.10-1.fc18 realmd 0.10] or later installed.
#: <pre>$ yum list realmd</pre>
# Remove the following packages, they should be installed by realmd as necessary.
#: <pre>$ sudo yum remove sssd samba-client adcli</pre>
|actions=
|actions=
# Perform the join command. Use the <code>--user=xxx</code> argument to specify your domain account name.
# Perform the join command. Use the {{command|<nowiki>--user=xxx</nowiki>}} argument to specify your domain account name, and replace dc.example.com with the fully-qualified hostname of the domain controller
#: <pre>$ realm join --user=User ad.example.com</pre>
#: {{command|<nowiki>realm join --user=(username) dc.example.com</nowiki>}}
#: You will be prompted for a password for the account.
#: You will be prompted for a password for the account
#: You will be prompted for Policy Kit authorization.
#: You will be prompted for PolicyKit authorization, because you are not running the command as root
#: On a successful join there will be no output.
#: On a successful join there will be no output
#: This can take up to a few minutes depending on how far away your Active Directory domain is.
#: This can take up to a few minutes depending on how far away your domain controller is.
 
|results=
|results=
# Check that the domain is now configured.
{{Domain_client_enrol_results}}
#: <pre>$ realm list</pre>
#: Make sure the domain is listed.
#: Make sure you have a <code>configured: kerberos-member</code> line in the output.
#: Make note of the <code>login-formats</code> line for the next command.
# Check that you can resolve domain accounts on the local computer.
#: <pre>$ getent passwd 'AD\User'</pre>
#: Make sure to use the quotes around the user name.
#: You should see an output line that looks like passwd(5) output. It should contain an appropriate home directory, and a shell.
#: Use the <code>login-formats</code> you saw above, to build a remote user name. It will be in the form of <code>DOMAIN\User</code>, where DOMAIN is the first part of your full Active Directory domain name.
# Check that you have an appropriate entry in your hosts keytab.
#: <pre>sudo klist -k</pre>
#: You should see several lines, with your host name. For example <code>2 HOSTNAME$@AD.EXAMPLE.COM</code>
# Check that you can use your keytab with kerberos
#: <pre>sudo kinit -k 'HOSTNAME$@AD.EXAMPLE.COM'</pre>
#: Make sure to use quotes around the argument, because of the characters in there. Make sure the hostname and domain are capitalized.
#: Use the principal from the output of the <code>klist</code> command above. Use the one that's capitalized and looks like <code>HOSTNAME$@DOMAIN</code>.
#: There should be no output from this command.
# If you have console access to a domain controller, you can use the ''Active Directory Users and Computers'' tool to see if that the computer account was created under the ''Computers'' section.
}}
}}


== Troubleshooting ==
== Troubleshooting ==


Use the <code>--verbose</code> argument to see details of what's being done during a join. Include verbose output in any bug reports.
Use the {{command|--verbose}} argument to see details of what's being done during a join. Include verbose output in any bug reports.
 
<pre>
$ realm join --verbose ad.example.com
</pre>
 
The selinux profile for realmd isn't yet stable, so you may want turn off enforcement. Please do still file bugs for the SElinux AVC notifications you see.
 
'''Known Issue [[https://bugzilla.redhat.com/show_bug.cgi?id=867873 Selinux]]:''' You need to turn off selinux to complete the join. Please do:
 
<pre>
$ sudo setenforce 0
</pre>
 
Please file the all realmd AVC's at this bug: https://bugzilla.redhat.com/show_bug.cgi?id=867873
 
<pre>
$ sudo grep realmd /var/log/audit/audit.log
</pre>


[[Category:Active_Directory_Test_Cases]] [[Category:Realmd_Test_Cases]]
[[Category:Active_Directory_Test_Cases]] [[Category:Realmd_Test_Cases]] [[Category:FreeIPA_Test_Cases]] [[Category:Server Acceptance Test Cases]]

Latest revision as of 23:19, 17 July 2018

Associated release criterion
This test case is associated with the Basic_Release_Criteria#freeipa-server-requirements release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion. If so, please file a bug and nominate it as blocking the appropriate milestone, using the blocker bug nomination page.
Associated release criterion
This test case is associated with the Basic_Release_Criteria#remote-authentication release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion. If so, please file a bug and nominate it as blocking the appropriate milestone, using the blocker bug nomination page.


Description

This test case ensures that you can enrol a machine as a client in an Active Directory or FreeIPA domain with the realm command, using sssd as an AD or FreeIPA client.

Setup

  1. Deploy a correctly-configured FreeIPA or Active Directory domain controller. You can follow:
    QA:Testcase_Server_role_deploy with the Domain Controller role to deploy a FreeIPA domain controller on Fedora 28 or earlier
    QA:Testcase_freeipa_trust_server_installation to deploy a FreeIPA domain controller on Fedora 29 or later
    QA:Testcase_Active_Directory_Setup to deploy an Active Directory domain controller
  2. Create at least one domain account, either a user or administrator. It's useful to test with both
  3. Ensure the test client has a fully-qualified hostname (e.g. client.example.com). Do not proceed if running hostname returns localhost or similar
  4. Ensure the realmd package is installed on the test client (e.g. su -c 'dnf install realmd')
  5. Remove the sssd, freeipa-client and samba-client packages (e.g. su -c 'dnf remove sssd samba-client') from the test client, they should be installed by realmd if necessary
  6. Unless you wish to test pending updates, disable the 'updates-testing' repository so realmd does not install packages from it: su -c 'dnf config-manager --set-disabled updates-testing'
  7. Install the krb5-workstation package to get the 'klist' and 'kinit' tools.
  8. The client must be capable of resolving the FreeIPA or Active Directory servers by FQDN. The easiest method of accomplishing this is to use Cockpit to modify the default DNS server address to be the IP address of the domain controller. If the domain controller is not running a DNS server, the alternative is to modify /etc/hosts on the client to contain the appropriate IP address for the domain controller FQDN.

How to test

  1. Perform the join command. Use the --user=xxx argument to specify your domain account name, and replace dc.example.com with the fully-qualified hostname of the domain controller
    realm join --user=(username) dc.example.com
    You will be prompted for a password for the account
    You will be prompted for PolicyKit authorization, because you are not running the command as root
    On a successful join there will be no output
    This can take up to a few minutes depending on how far away your domain controller is.

Expected Results

  1. Check that the domain is now configured: realm list
    Make sure the domain is listed
    Make sure you have a configured: kerberos-member line in the output
  2. Check that you can resolve domain accounts on the local computer
    For Active Directory:
    getent passwd 'DOMAIN\User' (DOMAIN is the netbios name, usually the first portion of the domain name, e.g. AD or SAMDOM; make sure to use the single quotes)
    For FreeIPA:
    getent passwd admin@domain (domain is the fully-qualified FreeIPA domain name, e.g. example.ipa)
    You should see an output line that looks like passwd output. It should contain an appropriate home directory, and a shell
  3. Check that you have an appropriate entry in your host's keytab: su -c 'klist -k'
    You should see several lines with your host name. For example 1 host/$hostname$@FQDN
  4. Check that you can use your keytab with kerberos: su -c 'kinit -k (principal)'
    Replace (principal) with the principal from the output of the klist command above. Use the one with the domain capitalized and that looks like host/hostname@DOMAIN) (FreeIPA) or TRUNCATED_HOSTNAME$@DOMAIN (Active Directory)
    There should be no output from this command
  5. If you are testing FreeIPA and have set up the FreeIPA Web UI, you can use it to see that the computer account was created under the Hosts section
  6. If you have are testing Active Directory and have console access to the domain controller, you can use the Active Directory Users and Computers tool to see if that the computer account was created under the Computers section
  7. Optionally, move on to QA:Testcase_domain_client_authenticate to ensure you can log in with a domain account.



Troubleshooting

Use the --verbose argument to see details of what's being done during a join. Include verbose output in any bug reports.

Retrieved from "https://fedoraproject.org/w/index.php?title=QA:Testcase_realmd_join_sssd&oldid=522521"