<?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: Local Logins Refused in AD Integration Scenarios</title>
	<atom:link href="http://blog.scottlowe.org/2008/01/09/local-logins-refused-in-ad-integration-scenarios/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.scottlowe.org/2008/01/09/local-logins-refused-in-ad-integration-scenarios/</link>
	<description>The weblog of an IT pro specializing in virtualization, storage, and servers</description>
	<lastBuildDate>Wed, 08 Feb 2012 17:13:47 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=</generator>
	<item>
		<title>By: Doug W</title>
		<link>http://blog.scottlowe.org/2008/01/09/local-logins-refused-in-ad-integration-scenarios/comment-page-1/#comment-41825</link>
		<dc:creator>Doug W</dc:creator>
		<pubDate>Fri, 03 Oct 2008 18:04:27 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/2008/01/09/local-logins-refused-in-ad-integration-scenarios/#comment-41825</guid>
		<description>This is a problem also in RHEL3 and I have only found one workaround for it which is to use NIS for passwd, shadow and groups. I tried building a later nss_ldap module on RHEL3 and was dogged with segmentation faults when performing lookups.

 This doesn&#039;t mean you are locked into using the shadow passwds given by NIS. I am using kerberos instead via your other instructions for Linux. Basically using NIS as the replacement for LDAP/AD in this case. http://blog.scottlowe.org/2007/01/15/linux-ad-integration-version-4/

BTW, it will generally fail on the first attempt if the NIS server can&#039;t be reached, but the second login try will succeed.</description>
		<content:encoded><![CDATA[<p>This is a problem also in RHEL3 and I have only found one workaround for it which is to use NIS for passwd, shadow and groups. I tried building a later nss_ldap module on RHEL3 and was dogged with segmentation faults when performing lookups.</p>
<p> This doesn&#8217;t mean you are locked into using the shadow passwds given by NIS. I am using kerberos instead via your other instructions for Linux. Basically using NIS as the replacement for LDAP/AD in this case. <a href="http://blog.scottlowe.org/2007/01/15/linux-ad-integration-version-4/" rel="nofollow">http://blog.scottlowe.org/2007/01/15/linux-ad-integration-version-4/</a></p>
<p>BTW, it will generally fail on the first attempt if the NIS server can&#8217;t be reached, but the second login try will succeed.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: slowe</title>
		<link>http://blog.scottlowe.org/2008/01/09/local-logins-refused-in-ad-integration-scenarios/comment-page-1/#comment-35410</link>
		<dc:creator>slowe</dc:creator>
		<pubDate>Tue, 12 Feb 2008 01:12:12 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/2008/01/09/local-logins-refused-in-ad-integration-scenarios/#comment-35410</guid>
		<description>Magnus,

Thanks for the update. I&#039;ll update the article accordingly!</description>
		<content:encoded><![CDATA[<p>Magnus,</p>
<p>Thanks for the update. I&#8217;ll update the article accordingly!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Magnus</title>
		<link>http://blog.scottlowe.org/2008/01/09/local-logins-refused-in-ad-integration-scenarios/comment-page-1/#comment-35399</link>
		<dc:creator>Magnus</dc:creator>
		<pubDate>Mon, 11 Feb 2008 19:14:06 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/2008/01/09/local-logins-refused-in-ad-integration-scenarios/#comment-35399</guid>
		<description>Scott,

After doing some research it turns out that even with the full AD integration enabled I can still log in to the Emergency Console using local authentication.

I would still rather VMware update to a bugfree nss-library but at least we won&#039;t have to use local groups.

Cheers,
Magnus</description>
		<content:encoded><![CDATA[<p>Scott,</p>
<p>After doing some research it turns out that even with the full AD integration enabled I can still log in to the Emergency Console using local authentication.</p>
<p>I would still rather VMware update to a bugfree nss-library but at least we won&#8217;t have to use local groups.</p>
<p>Cheers,<br />
Magnus</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: slowe</title>
		<link>http://blog.scottlowe.org/2008/01/09/local-logins-refused-in-ad-integration-scenarios/comment-page-1/#comment-35157</link>
		<dc:creator>slowe</dc:creator>
		<pubDate>Tue, 22 Jan 2008 11:55:38 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/2008/01/09/local-logins-refused-in-ad-integration-scenarios/#comment-35157</guid>
		<description>Rob,

I can only suggest having a look at the /etc/pam.d/system-auth file, which controls the authentication process, to see in what order esxcfg-auth specified the use of local files and Kerberos. Perhaps changing the order to UNIX first then Kerberos might help, if they aren&#039;t already in that order.</description>
		<content:encoded><![CDATA[<p>Rob,</p>
<p>I can only suggest having a look at the /etc/pam.d/system-auth file, which controls the authentication process, to see in what order esxcfg-auth specified the use of local files and Kerberos. Perhaps changing the order to UNIX first then Kerberos might help, if they aren&#8217;t already in that order.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob</title>
		<link>http://blog.scottlowe.org/2008/01/09/local-logins-refused-in-ad-integration-scenarios/comment-page-1/#comment-35098</link>
		<dc:creator>Rob</dc:creator>
		<pubDate>Thu, 17 Jan 2008 21:20:23 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/2008/01/09/local-logins-refused-in-ad-integration-scenarios/#comment-35098</guid>
		<description>I am having this same issue, but I followed the VMware document on enabling AD authentication which does not make any changes to nsswitch.con thus mine is still set to &quot;files&quot; on passwd, group, and shadow (no ldap).  Any ideas?</description>
		<content:encoded><![CDATA[<p>I am having this same issue, but I followed the VMware document on enabling AD authentication which does not make any changes to nsswitch.con thus mine is still set to &#8220;files&#8221; on passwd, group, and shadow (no ldap).  Any ideas?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic page generated in 2.425 seconds. -->
<!-- Cached page generated by WP-Super-Cache on 2012-02-09 10:48:26 -->

