Windows/Samba/AD
1 отговора
97 прегледа
Windows/Samba/AD
Здравейте!
Искам да попитам, дали има начин като направя нов потребител в Win2003 - Actove Directory, той да бьде реплициран автоматично на Suse-Linux Server, кьдето имам Samba-shares. идеята е, че като потребителя отвори няква папка, която всъщност е Samba-share, ако същия потребител съществува на линукс-а, този бива log-нат автоматиЧно. Аз обаЧе искам да си спестя слагането на същите user-и под линукс и искам информацията за тях да се взима от Active Directory. Така ще трябва да регистрирам user-и само под Win-a. Моля някой ако има идея да я сподели. Благодаря!
Искам да попитам, дали има начин като направя нов потребител в Win2003 - Actove Directory, той да бьде реплициран автоматично на Suse-Linux Server, кьдето имам Samba-shares. идеята е, че като потребителя отвори няква папка, която всъщност е Samba-share, ако същия потребител съществува на линукс-а, този бива log-нат автоматиЧно. Аз обаЧе искам да си спестя слагането на същите user-и под линукс и искам информацията за тях да се взима от Active Directory. Така ще трябва да регистрирам user-и само под Win-a. Моля някой ако има идея да я сподели. Благодаря!
Re: Windows/Samba/AD
Има начин ако конфигурираш правилно Samba сървъра. Прочети долната статия , по-специално копираните секции:
[линк]
SECURITY = SERVER
In this mode Samba will try to validate the username/password by passing it to another SMB server, such as an NT box. If this fails it will revert to security = user. It expects the encrypted passwords parameter to be set to yes, unless the remote server does not support them. However note that if encrypted passwords have been negotiated then Samba cannot revert back to checking the UNIX password file, it must have a valid smbpasswd file to check users against. See the chapter about the User Database in the Samba HOWTO Collection for details on how to set this up.
Note
This mode of operation has significant pitfalls, due to the fact that is activly initiates a man-in-the-middle attack on the remote SMB server. In particular, this mode of operation can cause significant resource consuption on the PDC, as it must maintain an active connection for the duration of the user's session. Furthermore, if this connection is lost, there is no way to reestablish it, and futher authenticaions to the Samba server may fail. (From a single client, till it disconnects).
Note
From the client's point of view security = server is the same as security = user. It only affects how the server deals with the authentication, it does not in any way affect what the client sees.
Note that the name of the resource being requested is not sent to the server until after the server has successfully authenticated the client. This is why guest shares don't work in user level security without allowing the server to automatically map unknown users into the guest account. See the map to guest parameter for details on doing this.
See also the section NOTE ABOUT USERNAME/PASSWORD VALIDATION.
See also the password server parameter and the encrypted passwords parameter.
SECURITY = ADS
In this mode, Samba will act as a domain member in an ADS realm. To operate in this mode, the machine running Samba will need to have Kerberos installed and configured and Samba will need to be joined to the ADS realm using the net utility.
Note that this mode does NOT make Samba operate as a Active Directory Domain Controller.
Read the chapter about Domain Membership in the HOWTO for details.
Default: security = USER
Example: security = DOMAIN
[линк]
SECURITY = SERVER
In this mode Samba will try to validate the username/password by passing it to another SMB server, such as an NT box. If this fails it will revert to security = user. It expects the encrypted passwords parameter to be set to yes, unless the remote server does not support them. However note that if encrypted passwords have been negotiated then Samba cannot revert back to checking the UNIX password file, it must have a valid smbpasswd file to check users against. See the chapter about the User Database in the Samba HOWTO Collection for details on how to set this up.
Note
This mode of operation has significant pitfalls, due to the fact that is activly initiates a man-in-the-middle attack on the remote SMB server. In particular, this mode of operation can cause significant resource consuption on the PDC, as it must maintain an active connection for the duration of the user's session. Furthermore, if this connection is lost, there is no way to reestablish it, and futher authenticaions to the Samba server may fail. (From a single client, till it disconnects).
Note
From the client's point of view security = server is the same as security = user. It only affects how the server deals with the authentication, it does not in any way affect what the client sees.
Note that the name of the resource being requested is not sent to the server until after the server has successfully authenticated the client. This is why guest shares don't work in user level security without allowing the server to automatically map unknown users into the guest account. See the map to guest parameter for details on doing this.
See also the section NOTE ABOUT USERNAME/PASSWORD VALIDATION.
See also the password server parameter and the encrypted passwords parameter.
SECURITY = ADS
In this mode, Samba will act as a domain member in an ADS realm. To operate in this mode, the machine running Samba will need to have Kerberos installed and configured and Samba will need to be joined to the ADS realm using the net utility.
Note that this mode does NOT make Samba operate as a Active Directory Domain Controller.
Read the chapter about Domain Membership in the HOWTO for details.
Default: security = USER
Example: security = DOMAIN