summaryrefslogtreecommitdiff
path: root/docs-xml
diff options
context:
space:
mode:
authorAndrew Bartlett <abartlet@samba.org>2012-09-14 09:29:51 -0700
committerAndrew Bartlett <abartlet@samba.org>2012-09-14 09:29:51 -0700
commit963664eccce0e7e221ab2c465a430b4d8e2e081b (patch)
tree037161498dbe6131ddbee068a77e77bc112fb858 /docs-xml
parentc5151b62679edd11940023e757378c7aac66933a (diff)
downloadsamba-963664eccce0e7e221ab2c465a430b4d8e2e081b.tar.gz
samba-963664eccce0e7e221ab2c465a430b4d8e2e081b.tar.bz2
samba-963664eccce0e7e221ab2c465a430b4d8e2e081b.zip
docs: Remove distinction between server and domain accounts
Accounts on a server become accounts on the DC when upgraded. If they do not then this is simply a bug (in say tdbsam), not a feature to be documented. Andrew Bartlett
Diffstat (limited to 'docs-xml')
-rw-r--r--docs-xml/Samba3-HOWTO/TOSHARG-ServerType.xml30
1 files changed, 0 insertions, 30 deletions
diff --git a/docs-xml/Samba3-HOWTO/TOSHARG-ServerType.xml b/docs-xml/Samba3-HOWTO/TOSHARG-ServerType.xml
index cb92766362..f0c07d2081 100644
--- a/docs-xml/Samba3-HOWTO/TOSHARG-ServerType.xml
+++ b/docs-xml/Samba3-HOWTO/TOSHARG-ServerType.xml
@@ -564,36 +564,6 @@ makes Samba act as a domain member. Read the manufacturer's manual before the wa
</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>