The LDAP client configuration part now contains help for users that can not

log in because of a missing shell.  When shells like bash are on different
paths (/bin/bash vs. /usr/local/bin/bash), entries need to be created in
/etc/shells and proper symlinks set to make this work.

Reviewed by:	wblock
Approved by:	wblock
Committed at:	Essen FreeBSD Hackathon
Differential Revision:	https://reviews.freebsd.org/D3194

en_US.ISO8859-1/articles/ldap-auth/article.xml

@@ -448,6 +448,34 @@ cn: tuser</programlisting>
 	correctly, then it will allow access.  Otherwise it will
 	fail.</para>
 
+      <para>Users whose shell is not in
+	<filename>/etc/shells</filename> will not be able to log in.
+	This is particularly important when
+	<application>Bash</application> is set as the user shell on
+	the LDAP server.  <application>Bash</application> is not
+	included with a default installation of &os;.  When installed
+	from a package or port, it is located at
+	<filename>/usr/local/bin/bash</filename>.  Verify that the
+	path to the shell on the server is set correctly:</para>
+
+      <screen>&prompt.user; <userinput>getent passwd <replaceable>username</replaceable></userinput></screen>
+
+      <para>There are two choices when the output shows
+	<literal>/bin/bash</literal> in the last column.  The first is
+	to change the user's entry on the LDAP server to
+	<filename>/usr/local/bin/bash</filename>.  The second option
+	is to create a symlink on the LDAP client computer so
+	<application>Bash</application> is found at the correct
+	location:</para>
+
+      <screen>&prompt.root; <userinput>ln -s /usr/local/bin/bash /bin/bash</userinput></screen>
+
+      <para>Make sure that <filename>/etc/shells</filename> contains
+	entries for both <literal>/usr/local/bin/bash</literal> and
+	<literal>/bin/bash</literal>.  The user will then be able to
+	log in to the system with <application>Bash</application> as
+	their shell.</para>
+
       <sect3 xml:id="client-auth-pam">
 	<title>PAM</title>