svn commit: samba-docs r989 - in trunk/Samba3-HOWTO: .

jht at samba.org jht at samba.org
Wed Oct 4 01:40:23 GMT 2006


Author: jht
Date: 2006-10-04 01:40:18 +0000 (Wed, 04 Oct 2006)
New Revision: 989

WebSVN: http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&root=samba-docs&rev=989

Log:
Applying edits suggested by Jon Johnson.
Modified:
   trunk/Samba3-HOWTO/TOSHARG-NetworkBrowsing.xml
   trunk/Samba3-HOWTO/TOSHARG-ServerType.xml


Changeset:
Modified: trunk/Samba3-HOWTO/TOSHARG-NetworkBrowsing.xml
===================================================================
--- trunk/Samba3-HOWTO/TOSHARG-NetworkBrowsing.xml	2006-09-30 16:58:18 UTC (rev 988)
+++ trunk/Samba3-HOWTO/TOSHARG-NetworkBrowsing.xml	2006-10-04 01:40:18 UTC (rev 989)
@@ -2199,20 +2199,20 @@
 To remove the stale shortcuts found in <emphasis>My Network Places</emphasis> which refer to what are now
 invalid shares or servers it is necessary to edit the Windows Registry under
 <literal>HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\</literal>. Edit the entry
-<literal>MountPoints2</literal> (on Windows XP and later, or <literal>MountPoints</literal> on
-Windows 2000 and earlier). Remove all keys named <literal>\\server\share</literal> (where 'server' and 'share' refer to a
+<literal>MountPoints2</literal> (on Windows XP and later, or <literal>MountPoints</literal> on Windows 2000
+and earlier). Remove all keys named <literal>\\server\share</literal> (where 'server' and 'share' refer to a
 non-existent server or share). Note that this must be done for every user profile that has such stale
-references.
+references. Alternately, you can delete the shortcuts from the MS Windows Explorer in <literal>My Network
+Places</literal> just by right-clicking them and selecting <emphasis>Delete.</emphasis>
 </para>
 
 <para>
 Samba users have reported that these stale references negatively affect network browsing with Windows, Samba,
-and Novell servers. They suspect it is a universal problem not directly related to the existence of a Samba
+and Novell servers. It is suspected to be a universal problem not directly related to the Samba
 server. Samba users may experience this more often due to Samba being somewhat viewed as an experimenter's
 toolkit. This results from the fact that a user might go through several reconfigurations and incarnations of
 their Samba server, by different names, with different shares, increasing the chances for having stale
-(invalid) cached share references. Strangely (or not so strangely), Windows does not seem to expire these
-references. I am not sure how or why the registry keys are created.
+(invalid) cached share references. Windows clients do not seem to expire these references.
 </para>
 
 <para>

Modified: trunk/Samba3-HOWTO/TOSHARG-ServerType.xml
===================================================================
--- trunk/Samba3-HOWTO/TOSHARG-ServerType.xml	2006-09-30 16:58:18 UTC (rev 988)
+++ trunk/Samba3-HOWTO/TOSHARG-ServerType.xml	2006-10-04 01:40:18 UTC (rev 989)
@@ -782,14 +782,13 @@
 <sect2>
 <title>Constantly Losing Connections to Password Server</title>
 
-<para>
-	<quote>
+<para><quote>
 Why does server_validate() simply give up rather than re-establish its connection to the
 password server?  Though I am not fluent in the SMB protocol, perhaps the cluster server
 process passes along to its client workstation the session key it receives from the password
 server, which means the password hashes submitted by the client would not work on a subsequent
-connection whose session key would be different. So server_validate() must give up.</quote>
-</para>
+connection whose session key would be different. So server_validate() must give up.
+</quote></para>
 
 <para>
 Indeed. That's why <smbconfoption name="security">server</smbconfoption>
@@ -799,6 +798,36 @@
 
 </sect2>
 
+<sect2>
+<title>Stand-alone Server is converted to Domain Controller &smbmdash; Now User accounts don't work</title>
+
+<para><quote>
+When I try to log in to the DOMAIN, the eventlog shows <emphasis>tried credentials DOMAIN/username; effective
+credentials SERVER/username</emphasis>
+</quote></para>
+
+<para>
+Usually this is due to a user or machine account being created before the Samba server is configured to be a
+domain controller. Accounts created before the server becomes a domain controller will be
+<emphasis>local</emphasis> accounts and authenticated as what looks like a member in the SERVER domain, much
+like local user accounts in Windows 2000 and later.  Accounts created after the Samba server becomes a domain
+controller will be <emphasis>domain</emphasis> accounts and will be authenticated as a member of the DOMAIN
+domain.
+</para>
+
+<para>
+This can be verified by issuing the command <command>pdbedit -L -v username</command>.  If this reports DOMAIN
+then the account is a domain account, if it reports SERVER then the account is a local account.
+</para>
+
+<para>
+The easiest way to resolve this is to remove and recreate the account; however this may cause problems with
+established user profiles. You can also use <command>pdbedit -u username -I DOMAIN</command>. You may also
+need to change the User SID and Primary Group SID to match the domain.
+</para>
+
+</sect2>
+
 </sect1>
 
 </chapter>



More information about the samba-cvs mailing list