2 files changed, 39 insertions, 10 deletions
diff --git a/docs/Samba3-HOWTO/TOSHARG-NetworkBrowsing.xml b/docs/Samba3-HOWTO/TOSHARG-NetworkBrowsing.xml
index fe199ae702..9b5178447d 100644
--- a/docs/Samba3-HOWTO/TOSHARG-NetworkBrowsing.xml
+++ b/docs/Samba3-HOWTO/TOSHARG-NetworkBrowsing.xml
@@ -2199,20 +2199,20 @@ requires manual intervention. This is a design feature of MS Windows and not any
 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>
diff --git a/docs/Samba3-HOWTO/TOSHARG-ServerType.xml b/docs/Samba3-HOWTO/TOSHARG-ServerType.xml
index 4fdc06d251..8aea1775e3 100644
--- a/docs/Samba3-HOWTO/TOSHARG-ServerType.xml
+++ b/docs/Samba3-HOWTO/TOSHARG-ServerType.xml
@@ -782,14 +782,13 @@ makes Samba act as a domain member. Read the manufacturer's manual before the wa
 <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 @@ is at best a nasty hack. Please use <smbconfoption name="security">domain</smbco
 
 </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>