From dabce971b0a08c2a85428b2db29152dce2cb4075 Mon Sep 17 00:00:00 2001 From: Jelmer Vernooij Date: Wed, 7 Apr 2004 10:40:50 +0000 Subject: - Better names for some files - Add the build system (This used to be commit 450386e3edfc59e0ad67c12998eddfc46b381250) --- docs/howto/DomainMember.xml | 1105 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1105 insertions(+) create mode 100644 docs/howto/DomainMember.xml (limited to 'docs/howto/DomainMember.xml') diff --git a/docs/howto/DomainMember.xml b/docs/howto/DomainMember.xml new file mode 100644 index 0000000000..72b00663f7 --- /dev/null +++ b/docs/howto/DomainMember.xml @@ -0,0 +1,1105 @@ + + + + &author.jht; + &author.jeremy; + &author.jerry; + &author.tridge; + &author.jelmer; + &person.gd;LDAP updates + + +Domain Membership + + +Domain Membership is a subject of vital concern. Samba must be able to +participate as a member server in a Microsoft Domain Security context, and +Samba must be capable of providing Domain machine member trust accounts, +otherwise it would not be able to offer a viable option for many users. + + + +This chapter covers background information pertaining to Domain Membership, +the Samba configuration for it, and MS Windows client procedures for joining a +domain. Why is this necessary? Because both are areas in which there exists +within the current MS Windows networking world and particularly in the +UNIX/Linux networking and administration world, a considerable level of +misinformation, incorrect understanding and a lack of knowledge. Hopefully +this chapter will fill the voids. + + + +Features and Benefits + + +MS Windows workstations and servers that want to participate in Domain Security need to +be made Domain Members. Participating in Domain Security is often called +Single Sign On or SSO for short. This +chapter describes the process that must be followed to make a workstation +(or another server &smbmdash; be it an MS Windows NT4 / 200x +server) or a Samba server a member of an MS Windows Domain Security context. + + + +Server TypeDomain Member +Samba-3 can join an MS Windows NT4-style domain as a native member server, an +MS Windows Active Directory Domain as a native member server, or a Samba Domain +Control network. Domain Membership has many advantages: + + + + +SAM + MS Windows workstation users get the benefit of SSO. + + + + Domain user access rights and file ownership/access controls can be set + from the single Domain Security Account Manager (SAM) database + (works with Domain Member servers as well as with MS Windows workstations + that are Domain Members). + + + + Only MS Windows NT4/200x/XP Professional + workstations that are Domain Members can use network logon facilities. + + + + Domain Member workstations can be better controlled through the use of + Policy files (NTConfig.POL) and Desktop Profiles. + + + + Through the use of logon scripts, users can be given transparent access to network + applications that run off application servers. + + + + Network administrators gain better application and user access management + abilities because there is no need to maintain user accounts on any network + client or server, other than the central Domain database + (either NT4/Samba SAM style Domain, NT4 Domain that is backend-ed with an + LDAP directory, or via an Active Directory infrastructure). + + + + + + +MS Windows Workstation/Server Machine Trust Accounts + + +Machine Trust Accounts +A Machine Trust Account is an account that is used to authenticate a client +machine (rather than a user) to the Domain Controller server. In Windows terminology, +this is known as a Computer Account. The purpose of the machine account +is to prevent a rogue user and Domain Controller from colluding to gain access to a +domain member workstation. + + + +The password of a Machine Trust Account acts as the shared secret for +secure communication with the Domain Controller. This is a security +feature to prevent an unauthorized machine with the same NetBIOS name +from joining the domain and gaining access to domain user/group +accounts. Windows NT/200x/XP Professional clients use machine trust +accounts, but Windows 9x/Me/XP Home clients do not. Hence, a +Windows 9x/Me/XP Home client is never a true member of a Domain +because it does not possess a Machine Trust Account, and, thus, has no +shared secret with the Domain Controller. + + + +A Windows NT4 PDC stores each Machine Trust Account in the Windows Registry. +The introduction of MS Windows 2000 saw the introduction of Active Directory, +the new repository for Machine Trust Accounts. A Samba PDC, however, stores +each Machine Trust Account in two parts, +as follows: + + + + A Domain Security Account (stored in the + passdb backend that has been configured in the + &smb.conf; file. The precise nature of the account information that is + stored depends on the type of backend database that has been chosen. + + + + The older format of this data is the smbpasswd database + that contains the UNIX login ID, the UNIX user identifier (UID), and the + LanMan and NT encrypted passwords. There is also some other information in + this file that we do not need to concern ourselves with here. + + + + The two newer database types are called ldapsam, and + tdbsam. Both store considerably more data than the + older smbpasswd file did. The extra information + enables new user account controls to be implemented. + + + + A corresponding UNIX account, typically stored in + /etc/passwd. Work is in progress to allow a + simplified mode of operation that does not require UNIX user accounts, but + this may not be a feature of the early releases of Samba-3. + + + + + +Machine Trust Accountscreating +There are three ways to create Machine Trust Accounts: + + + + + Manual creation from the UNIX/Linux command line. Here, both the Samba and + corresponding UNIX account are created by hand. + + + + Server Manager + Using the MS Windows NT4 Server Manager, either from an NT4 Domain Member + server, or using the Nexus toolkit available from the Microsoft Web site. + This tool can be run from any MS Windows machine as long as the user is + logged on as the administrator account. + + + + On-the-fly creation. The Samba Machine Trust Account is automatically + created by Samba at the time the client is joined to the domain. + (For security, this is the recommended method.) The corresponding UNIX + account may be created automatically or manually. + + + + +Manual Creation of Machine Trust Accounts + + +The first step in manually creating a Machine Trust Account is to manually +create the corresponding UNIX account in /etc/passwd. +This can be done using vipw or another add user command +that is normally used to create new UNIX accounts. The following is an example for +a Linux-based Samba server: + + + +useradd +vipw + +&rootprompt;/usr/sbin/useradd -g machines -d /dev/null -c "machine nickname" \ + -s /bin/false machine_name$ + +&rootprompt;passwd -l machine_name$ + + + +In the above example above there is an existing system group machines which is used +as the primary group for all machine accounts. In the following examples the machines group has +numeric GID equal 100. + + +chpass +On *BSD systems, this can be done using the chpass utility: + + + + +&rootprompt;chpass -a \ +'machine_name$:*:101:100::0:0:Windows machine_name:/dev/null:/sbin/nologin' + + + + +The /etc/passwd entry will list the machine name +with a $ appended, will not have a password, will have a null shell and no +home directory. For example, a machine named doppy would have an +/etc/passwd entry like this: + + + +doppy$:x:505:100:machine_nickname:/dev/null:/bin/false + + + +Above, machine_nickname can be any +descriptive name for the client, i.e., BasementComputer. +machine_name absolutely must be the NetBIOS +name of the client to be joined to the domain. The $ must be +appended to the NetBIOS name of the client or Samba will not recognize +this as a Machine Trust Account. + + + +Now that the corresponding UNIX account has been created, the next step is to create +the Samba account for the client containing the well-known initial +Machine Trust Account password. This can be done using the +smbpasswd command +as shown here: + + + + +&rootprompt;smbpasswd -a -m machine_name + + + + +where machine_name is the machine's NetBIOS +name. The RID of the new machine account is generated from the UID of +the corresponding UNIX account. + + + +Join the client to the domain immediately + + +Manually creating a Machine Trust Account using this method is the +equivalent of creating a Machine Trust Account on a Windows NT PDC using +Server Manager +the Server Manager. From the time at which the +account is created to the time the client joins the domain and +changes the password, your domain is vulnerable to an intruder joining +your domain using a machine with the same NetBIOS name. A PDC inherently +trusts members of the domain and will serve out a large degree of user +information to such clients. You have been warned! + + + + + +Managing Domain Machine Accounts using NT4 Server Manager + + +A working add machine script script is essential +for machine trust accounts to be automatically created. This applies no matter whether +one uses automatic account creation, or if one wishes to use the NT4 Domain Server Manager. + + + +SRVTOOLS.EXE +If the machine from which you are trying to manage the domain is an +MS Windows NT4 workstation or MS Windows 200x/XP Professional, +the tool of choice is the package called SRVTOOLS.EXE. +When executed in the target directory it will unpack SrvMgr.exe +and UsrMgr.exe (both are domain management tools for MS Windows NT4 workstation). + + + +Nexus.exe +If your workstation is a Microsoft Windows 9x/Me family product + you should download the Nexus.exe package from the Microsoft web site. +When executed from the target directory this will unpack the same tools but for use on +this platform. + + + +Further information about these tools may be obtained from the following locations: + + + + + + + + + + +Launch the srvmgr.exe (Server Manager for Domains) and follow these steps: + + + +Server Manager Account Machine Account Management + + From the menu select Computer. + + + + Click Select Domain. + + + + Click the name of the domain you wish to administer in the + Select Domain panel and then click + OK. + + + + Again from the menu select Computer. + + + + Select Add to Domain. + + + + In the dialog box, click the radio button to + Add NT Workstation of Server, then + enter the machine name in the field provided, and click the + Add button. + + + + + + +On-the-Fly Creation of Machine Trust Accounts + + +The second (and recommended) way of creating Machine Trust Accounts is +simply to allow the Samba server to create them as needed when the client +is joined to the domain. + + +Since each Samba Machine Trust Account requires a corresponding UNIX account, a method +for automatically creating the UNIX account is usually supplied; this requires configuration of the +add machine script option in &smb.conf;. This method is not required, however, corresponding UNIX +accounts may also be created manually. + + + + +Here is an example for a Red Hat Linux system. + + + +[global] +<...remainder of parameters...> +add machine script/usr/sbin/useradd -d /dev/null -g 100 \ + -s /bin/false -M %u + + + + + + +Making an MS Windows Workstation or Server a Domain Member + + +The procedure for making an MS Windows workstation or server a member of the domain varies +with the version of Windows. + + + + Windows 200x/XP Professional Client + + + When the user elects to make the client a Domain Member, Windows 200x prompts for + an account and password that has privileges to create machine accounts in the domain. + A Samba Administrator Account (i.e., a Samba account that has root privileges on the + Samba server) must be entered here; the operation will fail if an ordinary user + account is given. + + + + For security reasons, the password for this Administrator Account should be set + to a password that is other than that used for the root user in /etc/passwd. + + + + The name of the account that is used to create Domain Member machine accounts can be + anything the network administrator may choose. If it is other than root + then this is easily mapped to root in the file named in the &smb.conf; parameter + username map/etc/samba/smbusers. + + + + The session key of the Samba Administrator Account acts as an encryption key for setting the password of the machine trust + account. The Machine Trust Account will be created on-the-fly, or updated if it already exists. + + + + + Windows NT4 Client + + + If the Machine Trust Account was created manually, on the + Identification Changes menu enter the domain name, but do not + check the box Create a Computer Account in the Domain. + In this case, the existing Machine Trust Account is used to join the machine + to the domain. + + + + If the Machine Trust Account is to be created on-the-fly, on the Identification Changes menu enter the domain + name and check the box Create a Computer Account in the Domain. In this case, joining + the domain proceeds as above for Windows 2000 (i.e., you must supply a Samba Administrator Account when + prompted). + + + + + Samba Client + + Joining a Samba client to a domain is documented in + Domain Member Server. + + + + + + + +Domain Member Server + + +This mode of server operation involves the Samba machine being made a member +of a domain security context. This means by definition that all user +authentication will be done from a centrally defined authentication regime. +The authentication regime may come from an NT3/4-style (old domain technology) +server, or it may be provided from an Active Directory server (ADS) running on +MS Windows 2000 or later. + + + + +Of course it should be clear that the authentication backend itself could be +from any distributed directory architecture server that is supported by Samba. +This can be LDAP (from OpenLDAP), or Sun's iPlanet, or NetWare Directory +Server, and so on. + + + + +When Samba is configured to use an LDAP, or other identity management and/or +directory service, it is Samba that continues to perform user and machine +authentication. It should be noted that the LDAP server does not perform +authentication handling in place of what Samba is designed to do. + + + +Please refer to Domain Control, for more information regarding +how to create a domain machine account for a Domain Member server as well as for +information on how to enable the Samba Domain Member machine to join the domain +and be fully trusted by it. + + + +Joining an NT4-type Domain with Samba-3 + +Next table lists names that have been used in the remainder of this chapter. + +Assumptions + + + + + + NetBIOS name:SERV1 + + + Windows 200x/NT domain name:&example.workgroup; + + + Domain's PDC NetBIOS name:DOMPDC + + + Domain's BDC NetBIOS names:DOMBDC1 and DOMBDC2 + + + +
+ + +First, you must edit your &smb.conf; file to tell Samba it should now use domain security. + + + + Change (or add) your + security line in the [global] section +of your &smb.conf; to read: + + + + +securitydomain + + + + +Next change the workgroup line in the [global] +section to read: + + + + +workgroup&example.workgroup; + + + + +This is the name of the domain we are joining. + + + +You must also have the parameter encrypt passwords +set to yes in order for your users to authenticate to the NT PDC. +This is the default setting if this parameter is not specified. There is no need to specify this +parameter, but if it is specified in the &smb.conf; file, it must be set to Yes. + + + +Finally, add (or modify) a password server line in the [global] +section to read: + + + + +password serverDOMPDC DOMBDC1 DOMBDC2 + + + + +These are the primary and backup Domain Controllers Samba +will attempt to contact in order to authenticate users. Samba will +try to contact each of these servers in order, so you may want to +rearrange this list in order to spread out the authentication load +among Domain Controllers. + + + +Alternately, if you want smbd to automatically determine +the list of Domain Controllers to use for authentication, you may +set this line to be: + + + + +password server* + + + + +This method allows Samba to use exactly the same mechanism that NT does. The +method either uses broadcast-based name resolution, performs a WINS database +lookup in order to find a Domain Controller against which to authenticate, +or locates the Domain Controller using DNS name resolution. + + + +To join the domain, run this command: + + + + +&rootprompt;net join -S DOMPDC -UAdministrator%password + + + + +If the argument is not given, the domain name will be obtained from &smb.conf;. + + + +The machine is joining the domain DOM, and the PDC for that domain (the only machine +that has write access to the domain SAM database) is DOMPDC, therefore use the +option. The Administrator%password is the login name and +password for an account that has the necessary privilege to add machines to the +domain. If this is successful, you will see the message in your terminal window the +text shown below. Where the older NT4 style domain architecture is used: + +Joined domain DOM. + + + + +Where Active Directory is used: + +Joined SERV1 to realm MYREALM. + + + + +Refer to the net man page for further information. + + + +This process joins the server to the domain without having to create the machine +trust account on the PDC beforehand. + + + +This command goes through the machine account password change protocol, then writes +the new (random) machine account password for this Samba server into a file in the +same directory in which a smbpasswd file would be normally stored: + +/usr/local/samba/private/secrets.tdb +or +/etc/samba/secrets.tdb. + + + + +This file is created and owned by root and is not readable by any other user. It is +the key to the Domain-level security for your system, and should be treated as carefully +as a shadow password file. + + + +Finally, restart your Samba daemons and get ready for clients to begin using domain +security. The way you can restart your Samba daemons depends on your distribution, +but in most cases the following will suffice: + +&rootprompt;/etc/init.d/samba restart + + + + + + +Why Is This Better Than <parameter>security = server</parameter>? + + +Currently, domain security in Samba does not free you from +having to create local UNIX users to represent the users attaching +to your server. This means that if Domain user DOM\fred + attaches to your Domain Security Samba server, there needs +to be a local UNIX user fred to represent that user in the UNIX +file system. This is similar to the older Samba security mode +securityserver, +where Samba would pass through the authentication request to a Windows +NT server in the same way as a Windows 95 or Windows 98 server would. + + + +Please refer to Winbind: Use of Domain Accounts chapter, for information on a system +to automatically assign UNIX UIDs and GIDs to Windows NT Domain users and groups. + + + +The advantage to Domain-level security is that the +authentication in Domain-level security is passed down the authenticated +RPC channel in exactly the same way that an NT server would do it. This +means Samba servers now participate in domain trust relationships in +exactly the same way NT servers do (i.e., you can add Samba servers into +a resource domain and have the authentication passed on from a resource +domain PDC to an account domain PDC). + + + +In addition, with securityserver, every Samba +daemon on a server has to keep a connection open to the +authenticating server for as long as that daemon lasts. This can drain +the connection resources on a Microsoft NT server and cause it to run +out of available connections. With securitydomain, +however, the Samba daemons connect to the PDC/BDC only for as long +as is necessary to authenticate the user and then drop the connection, +thus conserving PDC connection resources. + + + +And finally, acting in the same manner as an NT server +authenticating to a PDC means that as part of the authentication +reply, the Samba server gets the user identification information such +as the user SID, the list of NT groups the user belongs to, and so on. + + + + +Much of the text of this document was first published in the Web magazine +LinuxWorld as the article +Doing the NIS/NT Samba. + + + + + + + +Samba ADS Domain Membership + + +Active Directory +ADSActive Directory +KDC +Kerberos +This is a rough guide to setting up Samba-3 with Kerberos authentication against a +Windows 200x KDC. A familiarity with Kerberos is assumed. + + + +Configure &smb.conf; + + +You must use at least the following three options in &smb.conf;: + + + +realmyour.kerberos.REALM +securityADS +The following parameter need only be specified if present. +The default setting is not present is Yes. +encrypt passwordsyes + + + +In case samba cannot correctly identify the appropriate ADS server using the realm name, use the +password server option in &smb.conf;: + +password serveryour.kerberos.server + + + + +You do not need a smbpasswd file, and older clients will be authenticated as +if securitydomain, although it will not do any harm and +allows you to have local users not in the domain. + + + + + +Configure <filename>/etc/krb5.conf</filename> + + +/etc/krb5.conf +Kerberos/etc/krb5.conf +With both MIT and Heimdal Kerberos, it is unnecessary to configure the +/etc/krb5.conf, and it may be detrimental. + + + +Microsoft Active Directory servers automatically create SRV records in the DNS zone +_kerberos.REALM.NAME for each KDC in the realm. This is part +of the installation and configuration process used to create an Active Directory Domain. + + + +MIT's, as well as Heimdal's, recent KRB5 libraries default to checking for SRV records, so they will +automatically find the KDCs. In addition, krb5.conf only allows specifying +a single KDC, even there if there may be more than one. Using the DNS lookup allows the KRB5 +libraries to use whichever KDCs are available. + + + +When manually configuring krb5.conf, the minimal configuration is: + + + + + +[libdefaults] + default_realm = YOUR.KERBEROS.REALM + +[realms] + YOUR.KERBEROS.REALM = { + kdc = your.kerberos.server + } + +[domain_realms] + .kerberos.server = YOUR.KERBEROS.REALM + + + +When using Heimdal versions before 0.6 use the following configuration settings: + +[libdefaults] + default_realm = YOUR.KERBEROS.REALM + default_etypes = des-cbc-crc des-cbc-md5 + default_etypes_des = des-cbc-crc des-cbc-md5 + +[realms] + YOUR.KERBEROS.REALM = { + kdc = your.kerberos.server + } + +[domain_realms] + .kerberos.server = YOUR.KERBEROS.REALM + + + + +kinit +Test your config by doing a kinit +USERNAME@REALM and +making sure that your password is accepted by the Win2000 KDC. + + + +With Heimdal versions earlier than 0.6.x you only can use newly created accounts +in ADS or accounts that have had the password changed once after migration, or +in case of Administrator after installation. At the +moment, a Windows 2003 KDC can only be used with a Heimdal releases later than 0.6 +(and no default etypes in krb5.conf). Unfortunately this whole area is still +in a state of flux. + + + +The realm must be in uppercase or you will get Cannot find KDC for +requested realm while getting initial credentials error (Kerberos +is case-sensitive!). + + + +Time between the two servers must be synchronized. You will get a +kinit(v5): Clock skew too great while getting initial credentials +if the time difference is more than five minutes. + + + +Clock skew limits are configurable in the Kerberos protocols. The default setting is +five minutes. + + + +You also must ensure that you can do a reverse DNS lookup on the IP +address of your KDC. Also, the name that this reverse lookup maps to +must either be the NetBIOS name of the KDC (i.e., the hostname with no +domain attached) or it can alternately be the NetBIOS name followed by the realm. + + + +The easiest way to ensure you get this right is to add a +/etc/hosts entry mapping the IP address of your KDC to +its NetBIOS name. If you do not get this correct then you will get a +local error when you try to join the realm. + + + +If all you want is Kerberos support in &smbclient; then you can skip +directly to Testing with &smbclient; now. +Create the Computer Account and +Testing Server Setup +are needed only if you want Kerberos support for &smbd; and &winbindd;. + + + + + +Create the Computer Account + + +As a user who has write permission on the Samba private directory (usually root), run: + +&rootprompt; net ads join -U Administrator%password + + + + +When making a Windows client a member of an ADS domain within a complex organization, you +may want to create the machine account within a particular organizational unit. Samba-3 permits +this to be done using the following syntax: + +&rootprompt; kinit Administrator@your.kerberos.REALM +&rootprompt; net ads join organizational_unit + + + + +For example, you may want to create the machine account in a container called Servers +under the organizational directory Computers\BusinessUnit\Department like this: + +&rootprompt; net ads join "Computers\BusinessUnit\Department\Servers" + + + + + + +Possible Errors + + + + ADS support not compiled in + Samba must be reconfigured (remove config.cache) and recompiled + (make clean all install) after the Kerberos libraries and headers files are installed. + + + net ads join prompts for user name + You need to login to the domain using kinit + USERNAME@REALM. + USERNAME must be a user who has rights to add a machine + to the domain. + + Unsupported encryption/or checksum types + + Make sure that the /etc/krb5.conf is correctly configured + for the type and version of Kerberos installed on the system. + + + + + + + + + +Testing Server Setup + + +If the join was successful, you will see a new computer account with the +NetBIOS name of your Samba server in Active Directory (in the Computers +folder under Users and Computers. + + + +On a Windows 2000 client, try net use * \\server\share. You should +be logged in with Kerberos without needing to know a password. If this fails then run +klist tickets. Did you get a ticket for the server? Does it have +an encryption type of DES-CBC-MD5? + + + +Samba can use both DES-CBC-MD5 encryption as well as ARCFOUR-HMAC-MD5 encoding. + + + + + +Testing with &smbclient; + + + +smbclient +On your Samba server try to login to a Win2000 server or your Samba +server using &smbclient; and Kerberos. Use &smbclient; as usual, but +specify the option to choose Kerberos authentication. + + + + + +Notes + + +You must change administrator password at least once after DC +install, to create the right encryption types. + + + +Windows 200x does not seem to create the _kerberos._udp and _ldap._tcp in +the default DNS setup. Perhaps this will be fixed later in service packs. + + + + + + +Sharing User ID Mappings between Samba Domain Members + + +Samba maps UNIX users and groups (identified by UIDs and GIDs) to Windows users and groups (identified by SIDs). +These mappings are done by the idmap subsystem of Samba. + + + +In some cases it is useful to share these mappings between Samba Domain Members, +so name->id mapping is identical on all machines. +This may be needed in particular when sharing files over both CIFS and NFS. + + +To use the LDAP ldap idmap suffix, set: + + +ldap idmap suffixou=Idmap,dc=quenya,dc=org + + +See the &smb.conf; man page entry for the ldap idmap suffix +parameter for further information. + + +Do not forget to specify also the ldap admin dn +and to make certain to set the LDAP administrative password into the secrets.tdb using: + +&rootprompt; smbpasswd -w ldap-admin-password + + + + + +Common Errors + + +In the process of adding/deleting/re-adding Domain Member machine accounts, there are +many traps for the unwary player and many little things that can go wrong. +It is particularly interesting how often subscribers on the Samba mailing list have concluded +after repeated failed attempts to add a machine account that it is necessary to re-install +MS Windows on the machine. In truth, it is seldom necessary to reinstall because of this type +of problem. The real solution is often quite simple and with an understanding of how MS Windows +networking functions, it is easy to overcome. + + + +Cannot Add Machine Back to Domain + + +A Windows workstation was re-installed. The original domain machine +account was deleted and added immediately. The workstation will not join the domain if I use +the same machine name. Attempts to add the machine fail with a message that the machine already +exists on the network &smbmdash; I know it does not. Why is this failing? + + + +The original name is still in the NetBIOS name cache and must expire after machine account +deletion before adding that same name as a Domain Member again. The best advice is to delete +the old account and then add the machine with a new name. + + + + + +Adding Machine to Domain Fails + + +Adding a Windows 200x or XP Professional machine to the Samba PDC Domain fails with a +message that, `The machine could not be added at this time, there is a network problem. +Please try again later.' Why? + + + +You should check that there is an add machine script in your &smb.conf; +file. If there is not, please add one that is appropriate for your OS platform. If a script +has been defined, you will need to debug its operation. Increase the log level +in the &smb.conf; file to level 10, then try to rejoin the domain. Check the logs to see which +operation is failing. + + + +Possible causes include: + + + + + The script does not actually exist, or could not be located in the path specified. + + + + Corrective action: Fix it. Make sure when run manually + that the script will add both the UNIX system account and the Samba SAM account. + + + + The machine could not be added to the UNIX system accounts file /etc/passwd. + + + + Corrective action: Check that the machine name is a legal UNIX + system account name. If the UNIX utility useradd is called, + then make sure that the machine name you are trying to add can be added using this + tool. Useradd on some systems will not allow any upper case characters + nor will it allow spaces in the name. + + + + +The add machine script does not create the +machine account in the Samba backend database, it is there only to create a UNIX system +account to which the Samba backend database account can be mapped. + + + + + + I Can't Join a Windows 2003 PDC + + Windows 2003 requires SMB signing. Client side SMB signing has been implemented in Samba-3.0. + Set client use spnegoyes when communicating + with a Windows 2003 server. + + + + -- cgit