QA:Testcase freeipav2 nis

{{QA/Test_Case
 * description=NIS testing.
 * setup=


 * 1) Make sure you have a working FreeIPA server (see QA:Testcase_freeipav2_installation)
 * 2) Make sure the CLI works as expected (see QA:Testcase_freeipav2_cli)
 * 3) This requires a separate client machine from the IPA server machine (see QA:Testcase_freeipav2_client_enrollment)


 * actions=

Configuring the IPA Server

 * NIS clients contact the portmapper service on a host to determine if it has a NIS server running, and if so, on which port it is that the NIS service is listening, so if the portmapper service (it may be named either portmap or rpcbind, depending on the version of Fedora you have) is not already running on the IPA server, start it:


 * 1) /sbin/service rpcbind start


 * Provided the IPA server is set up, you can turn on NIS services and enable user and group information to be served by using the ipa-nis-manage command:


 * 1) ipa-nis-manage enable


 * In order to allow the directory server to start providing NIS clients, it must be restarted when the plugin is first enabled, so you'll need to restart the directory server:


 * 1) /sbin/service ipa restart


 * Run rpcinfo -p to verify that your system's portmapper is now informing clients that a ypserv service is running, and on which port it is available.
 * If your system is running a firewall, ensure that port 111 (the portmapper service) and the port used by the ypserv service are both unblocked.

Configuring Clients

 * From the client's point of view, an IPA server with the NIS services enabled should look like any other NIS server. If your system includes system-config-authentication, use it to configure the system as a NIS client, using your IPA domain's name converted to lower-case as the name of the NIS domain, and the IPA server as your NIS server.  If you're on the same network as the server, you may also leave the server unspecified to let the client locate the server using broadcast.
 * Once the ypbind service is running on your client, you should be able to use ypcat and ypmatch, as usual, to show or search for specific entries in the passwd.byname , passwd.byuid , group.byname , group.bygid , netid.byname , and netgroup NIS maps, and the ypwhich command should indicate the server to which your client is bound.
 * Verify that when a user is added to or removed from the IPA domain, or their account is modified, that the relevant changes are visible when the user's entry is examined using ypmatch or other tools such as getent -s nis passwd, finger , or id.
 * Verify that when a group is added to or removed from the IPA domain, or the list of users who are members of the group is modified, that the relevant changes are visible when the group's entry is examined using ypmatch or getent -s nis group.

Password Hashes

 * You may notice that password hashes are not available, even when you attempt to retrieve entries as root. As this is the default behavior, a prospective client system would need to also be configured to use either Kerberos or LDAP to check user passwords.

A note about ypchfn, ypchsh, and yppasswd

 * The ypchfn, ypchsh , and yppasswd utilities use the yppasswd protocol to communicate with their server. Because the yppasswd protocol transmits the client's current password in unencrypted form to authenticate update requests, there are no plans to add support for yppasswd clients to IPA.

All the test steps should end with the specified results. }}
 * results=