<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: PAM &#8211; Locking out accounts when using external authentication</title>
	<atom:link href="http://www.bishnet.net/tim/blog/2009/10/09/pam-locking-out-accounts-when-using-external-authentication/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.bishnet.net/tim/blog/2009/10/09/pam-locking-out-accounts-when-using-external-authentication/</link>
	<description>"For a moment, nothing happened. Then, after a second or so, nothing continued to happen." -- HHGTTG</description>
	<lastBuildDate>Wed, 14 Oct 2009 16:57:29 +0100</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Tim Bishop</title>
		<link>http://www.bishnet.net/tim/blog/2009/10/09/pam-locking-out-accounts-when-using-external-authentication/comment-page-1/#comment-44270</link>
		<dc:creator>Tim Bishop</dc:creator>
		<pubDate>Sat, 10 Oct 2009 13:45:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.bishnet.net/tim/blog/?p=299#comment-44270</guid>
		<description>Hi David,

Thanks for the info. A similar solution to what you suggest is netgroups, or so I&#039;m told. The groups exist within the directory rather than on the local machines.

In my case though it&#039;s not quite how you describe. Each machine points at a separate OU in the LDAP directory. So we can control which accounts can access which machines using our central host management system.

The problem I&#039;m solving is the case where the user account does need to go on the machine (eg. it could be a Samba server), but the user shouldn&#039;t be able to log in.

Using the method you describe would work, but would require additional groups to be created and managed (and there&#039;s an annoying limit on the number of groups an individual can belong to with NFS). Groups in our setup are not currently managed by the central system either.

The route I&#039;ve chosen works using the password field sent by the management system, which we can control centrally. And my LDAP management code can then lock out (or unlock) an account on the LDAP server without ever touching the end system.

Thanks for your comments though, it&#039;s useful to know about other solutions. And it&#039;s refreshing to get a non-spam comment :D</description>
		<content:encoded><![CDATA[<p>Hi David,</p>
<p>Thanks for the info. A similar solution to what you suggest is netgroups, or so I&#8217;m told. The groups exist within the directory rather than on the local machines.</p>
<p>In my case though it&#8217;s not quite how you describe. Each machine points at a separate OU in the LDAP directory. So we can control which accounts can access which machines using our central host management system.</p>
<p>The problem I&#8217;m solving is the case where the user account does need to go on the machine (eg. it could be a Samba server), but the user shouldn&#8217;t be able to log in.</p>
<p>Using the method you describe would work, but would require additional groups to be created and managed (and there&#8217;s an annoying limit on the number of groups an individual can belong to with NFS). Groups in our setup are not currently managed by the central system either.</p>
<p>The route I&#8217;ve chosen works using the password field sent by the management system, which we can control centrally. And my LDAP management code can then lock out (or unlock) an account on the LDAP server without ever touching the end system.</p>
<p>Thanks for your comments though, it&#8217;s useful to know about other solutions. And it&#8217;s refreshing to get a non-spam comment <img src='http://www.bishnet.net/tim/blog/wp-includes/images/smilies/icon_biggrin.gif' alt=':D' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David Bell</title>
		<link>http://www.bishnet.net/tim/blog/2009/10/09/pam-locking-out-accounts-when-using-external-authentication/comment-page-1/#comment-44269</link>
		<dc:creator>David Bell</dc:creator>
		<pubDate>Sat, 10 Oct 2009 11:09:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.bishnet.net/tim/blog/?p=299#comment-44269</guid>
		<description>As I understand it, you have a bunch of machines using pam_krb5 for authentication (and also LDAP for NSS). You want some users to logon to some hosts, but not all hosts, i.e. you want to deny some users from logging on to certain hosts?

In GNU/Linux there exists a different approach than the one you have suggested for Solaris/FreeBSD. You can use the pam module pam_access which will then allow you to deny groups of users to logon:

http://blog.evad.info/2008/11/27/manage-access-to-your-linux-systems-via-groups-pam_access/

Sadly Solaris lacks an equivallent to pam_access, such that many people port Linux PAM&#039;s pam_access to Solaris. I don&#039;t believe there is an equivallent under FreeBSD either. 

Once you place pam_access in your PAM stack (under &quot;account&quot;) you can use one configuration file in /etc/security/ and you&#039;re done. The security file will remind you how how compat mode used to work in /etc/passwd in the days of NIS. You simply prefix the lines with &quot;-&quot; to deny and &quot;+&quot; to allow.

I hope this is helpful to you, however given its a Linux specific &quot;innovation&quot; which has not been replicated to other free operating systems its usefulness to you is probably limited. This, at any rate, is probably why pam_unix on Linux PAM is less useful than its cousins. 

Of course, this should work with external authentication even if &quot;auth&quot; isn&#039;t being consulted because &quot;account&quot; should still be consulted by the SSH Daemon (or some other access system). Let me know if you find a better solution, right now I&#039;m still using NIS at work (shudder) so the problem does not yet exist for us.</description>
		<content:encoded><![CDATA[<p>As I understand it, you have a bunch of machines using pam_krb5 for authentication (and also LDAP for NSS). You want some users to logon to some hosts, but not all hosts, i.e. you want to deny some users from logging on to certain hosts?</p>
<p>In GNU/Linux there exists a different approach than the one you have suggested for Solaris/FreeBSD. You can use the pam module pam_access which will then allow you to deny groups of users to logon:</p>
<p><a href="http://blog.evad.info/2008/11/27/manage-access-to-your-linux-systems-via-groups-pam_access/" rel="nofollow">http://blog.evad.info/2008/11/27/manage-access-to-your-linux-systems-via-groups-pam_access/</a></p>
<p>Sadly Solaris lacks an equivallent to pam_access, such that many people port Linux PAM&#8217;s pam_access to Solaris. I don&#8217;t believe there is an equivallent under FreeBSD either. </p>
<p>Once you place pam_access in your PAM stack (under &#8220;account&#8221;) you can use one configuration file in /etc/security/ and you&#8217;re done. The security file will remind you how how compat mode used to work in /etc/passwd in the days of NIS. You simply prefix the lines with &#8220;-&#8221; to deny and &#8220;+&#8221; to allow.</p>
<p>I hope this is helpful to you, however given its a Linux specific &#8220;innovation&#8221; which has not been replicated to other free operating systems its usefulness to you is probably limited. This, at any rate, is probably why pam_unix on Linux PAM is less useful than its cousins. </p>
<p>Of course, this should work with external authentication even if &#8220;auth&#8221; isn&#8217;t being consulted because &#8220;account&#8221; should still be consulted by the SSH Daemon (or some other access system). Let me know if you find a better solution, right now I&#8217;m still using NIS at work (shudder) so the problem does not yet exist for us.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
