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>
