Szeretném a Win2000-s klienseket a SAMBA tartományába beléptetni, de nem tudom. Kérem segítsetek.
[align=right][snapback]90959[/snapback][/align]

Ha lehetne egy kicsit konrétabban. A http://www.szabilinux.hu -n van egy jó Samba könyv.
A frissített kiadása – egyenlõre még csak ánglius nyelven – megvan. Kapok egy címet és megy. De bármi probléma van, segítek így is.

Jamesch

Köszönöm
Beírtam, hogy
adduser -m (gépnév),
smbpasswd -a -m (gépnév),
mert ezt olvastam, hogy az NT-s gépek esetében magát a munkaállomást is be kell léptettni a tartományba. Ezek után sem enged be a szerver.
[align=right][snapback]90971[/snapback][/align]

Ezt találtam a 2000-esrõl.
De ha kéred elküldöm a cuccot. Nagyon szuper.

Samba as the Primary Domain Controller

Samba 2.2 is able to handle the most desired functions of a primary domain controller in a Windows NT domain, handling domain logons and authentication for accessing shared resources, as well as supporting logon scripts, roaming profiles, and system policies.

TIP

You will need to use at least Samba 2.2 to ensure that PDC functionality for Windows NT/2000/XP clients is present. Prior to Samba 2.2, only limited user authentication for NT clients was present.

In this section, we will show you how to configure Samba as a PDC for use with Windows 95/98/Me and Windows NT/2000/XP clients. The two groups of Windows versions interact differently within domains, and in some cases are supported in slightly different ways. If you know you are going to be using only Windows 95/98/Me or Windows NT/2000/XP, you can set up Samba to support only that group. However, there isn’t any harm in supporting both at the same time.

TIP

If you would like more information on how to set up domains, see the file Samba-PDC-HOWTO.html in the docs/htmldocs directory of the Samba source distribution.

Samba must be the only domain controller for the domain. Make sure that a PDC isn’t already active, and that there are no backup domain controllers. Samba 2.2 is not able to communicate with backup domain controllers, and having domain controllers in your domain with unsynchronized data would result in a very dysfunctional network.

TIP

Although Samba 2.2 cannot function as, or work with, a Windows NT BDC, it is possible to set up another Samba server to act as a backup for a Samba PDC. For further information, see the file Samba-BDC-HOWTO.html in the docs/htmldocs directory of the Samba source distribution.

Configuring Samba to be a PDC is a matter of modifying the smb.conf file, creating some directories, and restarting the server.
Modifying smb.conf

First you will need to start with an smb.conf file that correctly configures Samba for workgroup computing, such as the one we created in Chapter 2, and insert the following lines into the [global] section:

[global]
; use the name of your Samba server instead of toltec
; and your own workgroup instead of METRAN
netbios name = toltec
workgroup = METRAN
encrypt passwords = yes

domain master = yes
local master = yes
preferred master = yes
os level = 65

security = user
domain logons = yes

; logon path tells Samba where to put Windows NT/2000/XP roaming profiles
logon path = \%Lprofiles%u%m
logon script = logon.bat

logon drive = H:
; logon home is used to specify home directory and
; Windows 95/98/Me roaming profile location
logon home = \%L%u.win_profile%m

time server = yes

; instead of jay, use the names of all users in the Windows NT/2000/XP
; Administrators group who log on to the domain
domain admin group = root jay

; the below works on Red Hat Linux – other OSs might need a different command
add user script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u

And after the [global] section, add these three new shares:

[netlogon]
path = /usr/local/samba/lib/netlogon
writable = no
browsable = no

[profiles]
; you might wish to use a different directory for your
; Windows NT/2000/XP roaming profiles
path = /home/samba-ntprof
browsable = no
writable = yes
create mask = 0600
directory mask = 0700

[homes]
read only = no
browsable = no
guest ok = no
map archive = yes

Now for the explanation. If you are comparing this example to the configuration file presented in Chapter 2, you will notice that the first three parameter settings are similar. We start out in the [global] section by setting the NetBIOS name of the Samba server. We are using the default, which is the DNS hostname, but are being explicit because the NetBIOS name is used in UNCs that appear later in smb.conf. The next two lines, setting the workgroup name and choosing to use encrypted passwords, are identical to our smb.conf file from Chapter 2. However, things are now a little different: even though it still reads „workgroup”, we are actually setting the name of the domain. For a workgroup, using encrypted passwords is optional; when using a domain, they are required.

The next four lines set up our Samba PDC to handle browsing services. The line domain master = yes causes Samba to be the domain master browser, which handles browsing services for the domain across multiple subnets if necessary. Although it looks very similar, local master = yes does not cause Samba to be the master browser on the subnet, but merely tells it to participate in browser elections and allow itself to win. (These two lines are yet more default settings that we include to be clear.) The next two lines ensure that Samba wins the elections. Setting the preferred master parameter makes Samba force an election when it starts up. The os level parameter is set higher than that of any other system, which results in Samba winning that election. (At the time of this writing, an os level of 65 was sufficient to win over all versions of Windows—but make sure no other Samba server is set higher!) We make sure Samba is both the domain and local master browser because Windows NT/2000 PDCs always reserve the domain master browser role for themselves and because Windows clients require things to be that way to find the primary domain controller. It is possible to allow another computer on the network to win the role of local master browser, but having the same server act as both domain and local masters is simpler and more efficient.

The next two lines in the [global] section set up Samba to handle the actual domain logons. We set security = user so that Samba will require a username and password. This is actually the same as in the workgroup setup we covered in Chapter 1 and Chapter 2 because it is the default. The only reason we’re including it explicitly is to avoid confusion: another valid setting is security = domain, but that is for having another (Windows or Samba) domain controller handle the logons and should never be found in the smb.conf of a Samba PDC. The next line, domain logons = yes, is what tells Samba we want this server to handle domain logons.

Defining a logon path is necessary for supporting roaming profiles for Windows NT/2000/XP clients. The UNC \%Lprofiles%u refers to a share held on the Samba server where the profiles are kept. The variables %L and %u are replaced by Samba with the name of the server and the username of the logged on user, respectively. The section in smb.conf defining the [profiles] share contains the definition of exactly where the profiles are kept on the server. We’ll get back to this topic a bit later in this chapter.

The logon script = logon.bat line specifies the name of an MS-DOS batch file that will be executed when the client logs on to the domain. The path specified here is relative to the [netlogon] share that is defined later in the smb.conf file.

The settings of logon drive and logon home have a couple of purposes. Setting logon drive = H: allows the home directory of the user to be connected to drive letter H on the client. The logon home parameter is set to the location of the home directory on the server, and again, %u is replaced at runtime by the logged on user’s username. The home directory is used to store roaming profiles for Windows 95/98/Me clients. These parameters tie into the [homes] share that we are adding, as we will explain a bit later.

Setting time server = yes causes Samba to advertise itself as a time service for the network. This is optional.

The domain admin group parameter exists as a short-term measure in Samba 2.2 to give Samba a list of users who have administrative privileges in the domain. The list should contain any Samba users who log on from Windows NT/2000/XP systems and are members of the Administrators or Domain Admins groups, if roaming profiles are to work correctly.

The last parameter to add to the [global] section is add user script, and you will need it only if one or more of your clients is a Windows NT/2000/XP system. We will tell you more about this in Section 4.2 later in this chapter.

The rest of the additions to smb.conf are the definitions for three shares. The [netlogon] share is necessary for Samba to handle domain logons because Windows clients need to connect to it during the logon process and will fail if the share does not exist. Other than that, the only function of [netlogon] is to be a repository for logon scripts and system-policy files, which we shall cover in detail later in this chapter. The path to a directory on the Samba server is given, and because the clients only read logon scripts and system-policy files from the share, the writable = no definition is used to make the share read-only. Users do not need to see the share, so we set browsable = no to make the share invisible.

The [profiles] share is needed for use with Windows NT/2000/XP roaming profiles. The path points to a directory on the Samba server where the profiles are kept, and in this case, the clients must be able to read and write the profile data. The create mask (read and write permitted for the owner only) and directory mask (read, write, and search permitted for the owner only) are set up such that a user’s profile data can be read and written only by the user and not accessed or modified by anyone else.

The [homes] share is necessary for our definitions of logon drive and logon home to work. Samba uses the [homes] share to add the home directory of the user (found in /etc/passwd ) as a share. Instead of appearing as „homes”, the share will be accessible on the client through a folder having the same name as the user’s username. We will cover this topic in more detail in Chapter 9.

At this point, you might want to run testparm to check your smb.conf file.
Creating Directories on the Samba Server

The [netlogon] and [profiles] shares defined in our new smb.conf file reference directories on the Samba server, and it is necessary to create those directories with the proper permissions:

# mkdir /usr/local/samba/lib/netlogon
# chmod 775 /usr/local/samba/lib/netlogon
# mkdir /home/samba-ntprof
# chmod 777 /home/samba-ntprof

The directory names we use are just examples. You are free to choose your own.
Restarting the Samba Server

At this point, the only thing left to do is restart the Samba server, and the changes will be put into effect:

# /etc/rc.d/init.d/smb restart

(or use whatever method works on your system, as discussed in Chapter 2.) The server is now ready to accept domain logons.
Adding Computer Accounts

To interact in a domain, a Windows NT/2000/XP system must be a member of the domain. Domain membership is implemented using computer accounts, which are similar to user accounts and allow a domain controller to keep information with which to authenticate computers on the network. That is, the domain controller must be able to tell if requests that arrive from a computer are coming from a computer that it „knows” as being part of the domain. Each Windows NT/2000/XP system in the domain has a computer account in the domain controllers’ database, which on a Windows NT/2000 hosted domain is the SAM database. Although Samba uses a different method (involving the smbpasswd file), it also treats computer accounts similarly to user accounts.

To create a computer account, an administrator configures a Windows NT/2000/XP system to be part of the domain. For Samba 2.2, the „domain administrator” is the root account on the Samba server, and you will need to run the command:

# smbpasswd -a root

to add the root user to Samba’s password database. In this case, do not provide smbpasswd with the same password as the actual root account on the server. Create a different password to be used solely for creating computer accounts. This will reduce the possibility of compromising the root password.

When the computer account is created, two things must happen on the Samba server. An entry is added to the smbpasswd file, with a „username” that is the NetBIOS name of the computer with a dollar sign ($) appended to it. This part is handled by the smbpasswd command, and you do not need to perform any additional action to implement it.

With Samba 2.2, an entry is also required in the /etc/passwd file[2] to give the computer account a user ID (UID) on the Samba server.

This account will never be used to log in to the Unix system, so it should not be given a valid home directory or login shell. To make this part work, you must set the add user script parameter in your Samba configuration file, using a command that adds the entry in the proper manner. On our Red Hat Linux system, we set add user script to:

/usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u

This command adds an entry in /etc/passwd similar to the following:

aztec$:x:505:100::/dev/null:/bin/false

Again, notice that the username ends in a dollar sign. The user account shown has a „home directory” of /dev/null, a group ID (GID) of 100, and a „login shell” of /bin/false. The -M flag in our useradd command prevents it from creating the home directory. Samba replaces the %u variable in the useradd command with the NetBIOS name of the computer, including the trailing dollar sign. The basic idea here is to create an entry with a valid username and UID. These are the only parts that Samba uses. It is important that the UID be unique, not also used for other accounts—especially ones that are associated with Samba users.

If you are using some other variety of Unix, you will need to replace our useradd command with a command that performs the same function on your system. If a command such as useradd does not come with your system, you can write a shell script yourself that performs the same function. In any case, the command should add a password hash that does not correspond to any valid password. For example, in the /etc/shadow file of our Linux server, we find the following two lines:

jay:%1%zQ7j7ok8$D/IubyRAY5ovM3bTrpUCn1:11566:0:99999:7:::
zapotec$:!!:11625:0:99999:7:::

The first line is for jay’s user account. The second field is the password hash—the long string between the first and second colons. The second line is for the computer account of zapotec, a domain member server. Its „username” ends with a dollar sign ($), and the second field in this case has been set to „!!”, which is an arbitrary string not produced from any password. Therefore, there is no valid password for this account on the Linux host. Just about any ASCII string can be used instead of „!!”. For example, you could use „DISABLED” instead.

TIP

It is possible to create the entries for /etc/passwd and smbpasswd manually; however, we suggest this method be used very carefully, and only for initial testing, or as a last resort. The reason for this is to maintain security. After the computer account has been created on the server, the next Windows NT/2000/XP system on the network with a matching NetBIOS name to log on to the domain will be associated with this account. This allows crackers a window of opportunity to take over computer accounts for their own purposes.

Jamesch

Köszönöm
Beírtam, hogy
adduser -m (gépnév),
smbpasswd -a -m (gépnév),
mert ezt olvastam, hogy az NT-s gépek esetében magát a munkaállomást is be kell léptettni a tartományba. Ezek után sem enged be a szerver.
[align=right][snapback]90971[/snapback][/align]

Még valami. http://www.webmin.com
Letöltöd, felteszed és egy böngészõn keresztül azt csinálsz a Linux-al amit akarsz. Ezer éve ezt használom, parancssor csak a script vagy a programírásnál szerepel nálam.

Jamesch

Hi!

Van egy nagy problémám: hugomnak szétesett a munkahelyi gépében a vinyó, beépítettem egy másikat, de nem férek hozzá a Samba szerverhez (Debian), hogyan tudom beállítani, hogy az

Gondolom kell valamilyen Samba csomagot telepíteni WindowsXP-re, de sehol nem találom, a samba.org-on .tar.gz állományt találok, de ez így elsõre nem a Win-re való 🙂
Honnan tudom letölteni?

Semmit sem kell letölteni!!!
a SAMBA pontosan a win-szerû megosztások létrehozására készült, ha az XP-s megosztásokat szeretnéd elérni, akkor általában a legjobb megoldás az smbmount használata, ha kicsit konkretizálsz, akkor én is 🙂