Topic: SME 9 as a PDC

[michelandre]

Hi all,

- I made sme 9.1 PDC controller
- Server name: sme-9
- Sations: XP & Win-7
- Goal: replace Micro$oft server with SME-9

Following: https://wiki.contribs.org/SME_Server:Documentation:FAQ/fr#Upgrading_Server
I modify maxGroupNameLength:

Code: [Select]

# /sbin/e-smith/db configuration set maxGroupNameLength 20

# /sbin/e-smith/signal-event console-save

# /sbin/e-smith/db configuration show  maxGroupNameLength
maxGroupNameLength=20

- I created groups on SME:
Description       Name
Domain Admins     admin-windows
Domain users      usager-windows
Power users       super-usager-windows

- I installed "shared folder" according to: https://wiki.contribs.org/SharedFolders
I created a shared folder: partage_sme
I gave r/w to group "Domain users" / "usager-windows"

- I installed Smeserver-tw-logonscript: https://wiki.contribs.org/Smeserver-tw-logonscript
In the logon script: "usager-windows.bat" for the group: "Domain users" / "usager-windows"

Code: [Select]

net use K: \\SME-9\partage_sme    

- From the Forum: https://forums.contribs.org/index.php?topic=42835.0

...
Domain Users:
A global group that, by default, includes all user accounts in a domain. When you create a user account in a domain, it is added to this group automatically.
...

- I created user: toto

*** I didn't include toto in "Domain users" / "usager-windows" and there is no mapped drive K:

*** I include toto in "Domain users" / "usager-windows" and there is a mapped drive K:

It looks like when you create a new user, he is not automatically included in the group "Domain users" / "usager-windows".
Both stations XP & Win-7 did exactly the same thing.

QUESTIONS:
Is the new user automatically included in the group "Domain users"?
If yes, where I went wrong?
Is it a difference with global an local group?


- My next test will be to verify other groups but mostly Power users
According to: https://msdn.microsoft.com/en-us/library/bb726982.aspx
There is a lot of other groups to use.

From: https://wiki.contribs.org/SME_Server:Documentation:Administration_Manual:Chapter9#Setting_Windows_Admin_Rights
Group Description    Domain Rights
Domain Admins    admin
Domain Users     shared (everyone)
Domain Guests    nobody

There is no other groups like Power users

QUESTIONS:
Is it OK to create any group or just Domain Admins, Domain Users, and Domain Guests?

Any comment appreciated,

Michel-André

[Daniel B.]

The special groups you've created are mapped to local groups on your windows client. For example, members of your sme groups Domain Admins will be automatically admin users of workstations. You still need to define membership on sme side

[michelandre]

Hi Daniel B.

Thank you for your fast response.

Are you saying that a new created user is not automatically included in group "Domain users" and that he have to be included manually?

Thank you again,

Michel-André

[Jean-Philippe Pialasse]

No, new created user are not included in any group. I imagine that in some cas that could be handy to have new user limited to email or something else. Keep in mind that sme can also work in a place without any windows.


However, what you ask could be a new feature request or a possible contrib where you can select a list of default group to be part of on creation of new user

[janet]

michelandre

Good management practise when you create an ibay, is to allow access rights to that ibay ONLY for a specific unique group.
eg ibay1
ibay1group

You might have say 6 ibays & have say  3 or 4 or 6 different access rights for different groups of users.
Sometimes multiple ibays can be "owned" by the same groupname.
eg ibay1
ibay2
ibay3
ibaygroupX

Then when you create new users you add the user to either one or various groups (simply done by ticking the box against existing groups), depending which ibays you want them to have access to & not have access to.

The above is for ibays, I assume it will be similar for shared folders (I think it is based on ibays) but I do not currently use shared folders contrib so cannot say for sure.

When you are first setting up your sme server, it is a wise idea to think about future management control of access rights, think ahead before implementing too much & come up with a structure & a naming policy that allows you to easily use/implement all of sme server features later eg also consider the use of pseudonyms & pseudonyms of pseudonyms (...of pseudonyms) (very powerful feature).

Look in the wiki.

[Daniel B.]

Are you saying that a new created user is not automatically included in group "Domain users" and that he have to be included manually?

Every user is by default automatically member of a hidden group named 'shared' on SME, which correspond to 'Domain Users'. By creating a new user, even if he's not a member of any group on SME, he will be able to log into a Windows workstation of the domain and will be seen as a member of the "Domain Users". But access to shared folders is seen from SME point of view only. If you want t user to access its content, he must be member of a group having access (or set an ACL for the user directly)

[michelandre]

Hi all,

Thank you Jean-Philippe Pialasse.

No, new created user are not included in any group.

You means Windows group. But he is automatically a member of "shared".

Code: [Select]

# cat /etc/group | egrep toto
shared:x:500:...,toto,...
toto:x:5018:
So I conclude that the right to logon to a Domain station depends on the membership to the group "shared" and not to the membership to the group "Domain users". That is why the user "toto" is able to logon to a Domain station because I didn't include him in the group "Domain users".

Thank you janet.
I am considering shared folder because I can control the  HTTP/HTTPS access the same way as with i-bays but I can also control the SMB/CIFS access (visible, masked, no access),  the recycle bin, and the time to keep the file.
I will still use i-bays for other groups.

Thank you Daniel B.

hidden group named 'shared' on SME, which correspond to 'Domain Users'

If 'shared' correspond to 'Domains Users' toto would run the script "usager-windows.bat" which is not the case.

https://technet.microsoft.com/en-us/library/dd277404.aspx
Logon Right: A user right that is assigned to a user and that specifies the ways in which a user can log onto a system. An example of a logon right is the right to log on to a system remotely.

Explanation # 1:
- toto is a member of "shared" and not a member of "Domain users".
- ***** the "Logon Right" is given to the group "shared" and that is why toto is able to logon to the station.
- toto is not able to run the logon script "usager-windows.bat" because he is not a member of the group "Domains users".
- the group "shared" has no relation to the group "Domain users"

http://serverfault.com/questions/391940/a-user-in-multiple-user-groups-not-receiving-correct-permissons
...
NTFS permissions
In regards to NTFS permissions: NTFS permissions are cumulative and use a least restrictive mechanism. A user who is a member of multiple groups will have the least restrictive permissions of the culmination of the NTFS permissions granted to each group.

Share permissions
In regards to Share permissions: When combined with NTFS permissions, the more restrictive permissions prevail. For example, if the user or group has NTFS Full Control permissions but the Share permissions are Everyone|Read then the effective permissions (the more restrictive permissions) for any user or group is Read. To determine the effective permissions for a user or group, determine the effective NTFS permissions then determine the effective Share permissions, then determine the more restrictive permissions of the "combined" NTFS and Share permissions and those are the effective permissions for the user or group.
...

On the a station, I opened a command windows and run:

Code: [Select]

net use K: \\SME-9\partage_sme
which is the same as the content of the logon script "usager-windows.bat" and success.
In Windows explorer, I see a new mapped drive K: but if I click on it, ACCESS DENIED

Explanation # 2:
- toto is a member of "shared" and not a member of "Domain users".
- ***** because of NTFS permissions and that toto is a member of "shared" and since "shared" has the least restrictive permissions, toto is able to logon to the station.
- toto is not able to run the logon script "usager-windows.bat" because he is not a member of the group "Domains users".
- toto has no right to the shared folder but he is still able to map a drive to it even if he can't access its content.
- the group "shared" has no relation to the group "Domain users"

I would like to understand, any suggestion appreciated,

Michel-André

[Stefano]

I never had any issue to have domain users created on SME and with no group (apart of default shared) to execute logon.bat scripts

[michelandre]

Hi all,

Thank you Stefano,

It is not the standard logon.bat script. It is the "usager-windows.bat" which is a shared folder longon script and different from logon.bat script.

Michel-André

[Daniel B.]

It is the "usager-windows.bat" which is a shared folder longon script and different from logon.bat script.

I don't understand what you mean. Shared folders have no support for logon script (well you can store logon scripts as any other file)

[michelandre]

Hi all,

Thank you Daniel B.

Sorry, my mistake. It is a group script that I used to map a drive to a "shared folder" if the user is a member of that group.

Michel-André

[janet]

michelandre

To ask a basic question, did you actually join the workstations in question to the DOMAIN ?
Until you do that you will not be able to run the netlogon.bat script automatically (or a custom version), & will not be able to access any ibays (or I imagine shared folders) as your workstation is not TRUSTED.

Also you must make users members of a group that owns access rights to the ibay or shared folder, or you will not be able to access those resources from your workstation as a particular logged in DOMAIN user eg YOURDOMAIN\username (when logging in to Windows).

Also SME server supports a Windows NT style DOMAIN feature set, not an Active Directory feature set, so some Microsoft features are not supported.

I suggest you get standard DOMAIN login & access to standard ibays sorted out first, this will prove that your DOMAIN has been joined by workstations, that netlogon.bat is operating, & groups & users are configured correctly. Then when that is proven to work, you can then sort out using shared folders.


Also refer to this section of the smeserver-tw-logonscript contrib

" Setup

After the installation you will find that there is a new item on the server-manager panel called I-bay letters. It takes the user to a page that will display the list of I-bay names, descriptions, associated groups and a 4th column with a drop down option that allows a Windows drive letter to be associated with that I-bay. Once the settings are saved, a computer currently joined to the domain will map that drive letter to the I-bay if the user belongs to the I-bay group. Right on the bottom of the list you can define the user's home folder (most likely H:). If you make any changes to the home drive you have to make sure you reload the Workgroup settings (which will restart Samba).

Further down, there is a list of all groups and descriptions followed by a column named "Custom Batch file". If the user clicks one of the links they can create a batch file that will be executed when a user belonging to that particular group logs in.

The file is created under the /home/e-smith/files/samba/netlogon/custom folder. If the group is called 'all-users' a file 'all-users.bat' will be created under /home/e-smith/files/samba/netlogon/custom.

In some situations it is required that a custom command is run for a particular user, in that case a file called 'username.bat' should be created under /home/e-smith/files/samba/netlogon/custom and it will be executed when that user logs in. "

[michelandre]

Hi all,

Thank you very much janet,

Yes, all the testing stations joined the Domain. No problem with that.
I did all what you mentioned. All the users have their home directory mapped to H: by the i-bay letter panel.

I put all the standard users in the group "Domains users" so they have minimum rights; they cannot install programs which is what I want.

The problem I have is with "Power users". I would like some of the more knowledgeable users to be able to install programs they want to use without being in the group "Domain admins" (too much rights).

There is the group "Power users" which is suppose to be able to install programs without all the "Domain admins" rights. I tried that with no success...

Now I am looking at the SME set command and I found:

Code: [Select]

# net groupmap list | egrep shared
Domain Users (S-1-5-21-3664030659-1427530257-712955138-513) -> shared

I think this is the way the group "Domain Users" is mapped to the group "shared"

I wil investigate:

Code: [Select]

   GROUPMAP ADD
       Add a new group mapping entry:

           net groupmap add {rid=int|sid=string} unixgroup=string \
                [type={domain|local}] [ntgroup=string] [comment=string]

According to "Group Mapping: MS Windows and UNIX": https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/groupmapping.html.

Starting with Samba-3, new group mapping functionality is available to create associations between Windows group SIDs and UNIX group GIDs. The groupmap subcommand included with the net tool can be used to manage these associations.

It should be possible to associate the group "Power Users" to a SME group. That will resolve my problem.

Michel-André

[michelandre]

Hi all,

Acoording to: https://support.microsoft.com/en-us/kb/2028493

In Windows Vista and later Windows operating systems, the permissions and rights that are associated with the Power Users group have been removed.

So I think the solution is to have the user install the programs they want in their home directory.

Michel-André

[Stefano]

No. In a domain environment, domain admin or local admin install the needed SW on PC and domain user just use it

[michelandre]

Hi all,

Thank you Stefano for your comment.

Can I ask you how you stop them from installing in their home directory?

Michel-André

[Stefano]

I'd do some tests, but nowadays many apps are able to install themselves on user's homedir without high privileges..

in W2000/WXP there was the possibility to use poledit to create some kind of group policy configuration to be loaded on the client via logon script, now M$ changed so many things and (IIRC) this approach is not supported anymore

I suggest you to install on M$ client a sw that redirects all system events to SME's syslog and then parse every night logs looking for what you don't want users to do..

then, when you see that user jondoe installed something, a simple mail with "guy, I see you, please uninstall" is enough

[michelandre]

Hi all,

The SME server 9.1 is a PDC
Local IP: 10.10.100.38
External IP: 100.100.100.100/255.255.255.0

Station: Windows // IP address 100.100.100.102/255.255.255.0

- I created a Shared Folder.
- The following settings control the access of this shared folder using the HTTP/HTTPS protocol.
  "Web Access"  =  Entire Internet (password required outside local network)
  "Force secure connections"  =  Enabled
 
PROBLEM
- With a Windows station, member or not of the domain.
- User, member or not of the domain.
- User with or without Permissions on the Shared Folder.
Any user can access directly the Shared Folder at URL http://server_external_IP/shared_folder_name without a password and download any file.
On access, the URL is changing from http: to https: so the other parameter Force secure connections is working properly.

It works exactly as Local network (no password required) but the station is on the external lan.

I think that this is not normal,

Michel-André

[janet]

michelandre

Any user can access directly the Shared Folder at URL http://server_external_IP/shared_folder_name without a password and download any file.
.....It works exactly as Local network (no password required) but the station is on the external lan.

What is an external LAN ? Users need to be on the external WAN.
Are they really accessing from an external location ?

I think that this is not normal...

If so then lodge a bug report (I suppose against the contrib).

[michelandre]

Hi all,

Thanks to Daniel B. all is resolved.

For the Shared folder problem:
In Server Manager, I remove the network of the station from "Security / Remote access / Remote Management" and all is working fine.

Michel-André