SME Server:Documentation:Administration Manual:Chapter9
User accounts should be set up for each person in your organization. A user account includes separate, password-protected email and file storage areas.
If this is the first time you are setting up user accounts for your organization, you will need to establish what your naming convention will be. Let's assume you've decided that the account name should consist of first initial and last name. So, if you have an employee named Fred Frog, Fred's user account would be "ffrog". Assuming your domain name is tofu-dog.com, Fred's email address would be "email@example.com". Fred's file directory on the server would also be named "ffrog". There are some basic rules built into the server as to what constitutes a valid account name. The account name must contain only lower-case letters and numbers and should start with a lower-case letter (not a number).
User account names are limited to twelve characters to maintain consistency with various versions of Windows. Longer names can be created for email through the >Pseudonyms panel. For your information, pseudonyms of "firstname.lastname" and "firstname_lastname" are automatically created for each account.
In the "User Accounts" section of the server-manager, you will see a list of your current accounts. If you haven't already created any accounts, select "Click here" and fill in the requested information - the account name (the part of the email address that comes before "@"), the person's name, address, department, company and phone number. As a convenience, the defaults that you entered in the "Directory" section of the server-manager appear each time you create a new account. You can, if necessary, modify the information for each user as you create the account.
From the list of user accounts, you can easily modify or remove a user account (by clicking on "modify" or "remove" next to the user name) or set the user's password. User accounts are locked out and cannot be used until you set the initial password for each account . As a reminder of this, user accounts appear in red until the password is changed. (In the example shown here, the administrator has not yet changed the password for user "Sally Salmon").
Disabling User Accounts
There may be times when you do not wish to delete a user account but instead merely want to disable it. For instance, when an employee leaves the company, you may want to immediately remove their access to the server, but still keep their files or email address active until the information can be examined. To disable any user account on your server, just click on the Lock Account link on the User Accounts server-manager panel. As soon as you click the link, the account will be locked out. The user will no longer be able to retrieve email or connect to any files or other resources on the server.
When an account is disabled, email will still be received for that user name, but the user will be unable to retrieve the email. As noted above, if a user account is set to forward email to an external email address, the email will be forwarded to that external address. To prevent this, you will need to modify the properties for that user account.
To re-enable the user account, you need to reset the password using the link on the User Accounts server-manager panel.
Changing User Passwords
Once they have an active account, your users can set their own passwords by accessing the user-password URL which is only accessible from Local Networks. They do this through their web browsers by visiting the URL www.yourdomain.xxx/user-password (where "www.yourdomain.xxx" is the web server name you entered into the server console). The staff at The Pagan Vegan would visit the URL www.yourdomain.xxx/user-password .
To make the change, a user would enter his or her account name (the characters before "@"), the old password and the new password (to ensure accuracy, the screen asks for the new password twice). Note that changing the password for a user in the server-manager overrides any previous password entered by your user. Therefore, when a user forgets his password, simply reset it in the server- manager.
The following settings are available to specify the password strength on SME Server:
|strong||The password is passed through Cracklib for dictionary type word checking as well as requiring upper case, lower case, number, non alpha and a mimimum length of 7 characters.|
|normal||The password requires upper case, lower case, number, non alpha and a minimum length of 7 characters.|
|none|| The password can be anything as no checking is done.
Please note that "none" does not mean no password, it just means no password strength checking, so you can enter any (weak) password you want as long as it is at least 7 characters long.
This screen allows you to create, remove or change user groups, which are simply lists of people with a shared interest - for example, they work in the same department or are collaborating on a project. The user group function serves two purposes in the SME Server: it permits email to be sent conveniently to a group of users, and it allows the system administrator to associate groups of users with a single information bay (i-bay).
Creating a new group is a simple three-step process. You enter the group name (as with account names, these should begin with a lower-case letter and consist only of lower-case letters and numbers), followed by a brief description. Finally, check the boxes next to the names of the users who should be associated with that group.
After you add (or remove) a user account from a group, the user must log out and log back in for those changes to take effect. Until the user does so, he or she will still have their old group membership information. For instance, suppose you create a new group "sales" and assign user "ffrog" (Fred Frog) to that group. You then create a new i-bay called "salesinfo" that only the "sales" group can access, until Fred logs out and then logs back in he will not have access to the new "sales" group and its ibay "salesinfo".
Setting Windows Admin Rights
If you are using SME Server as a domain controller and the windows workstations have joined the domain then by adding users to special groups you are able to change the rights a users has on that workstation.
The domain always has three groups created, assigned as follows:
|Group Description||Domain Rights|
|Domain Users||shared (everyone)|
If you create a group and name it whatever you want but put one of the above for the description then the newly created group will replace the above mapping. So if you create a group called "admins" and give it a description of "Domain Admins" then anyone you assign to this group will be a domain admin and also a local admin on ANY box that has joined the domain.
You can also create a less privileged group "Power Users"
see https://ss64.com/nt/syntax-security_groups.html and https://www.howtogeek.com/school/windows-network-sharing/lesson1/all/ for the rights granted to the different groups.
By default, there is no size limit on the files a user may store on the server nor the amount of email that can be received. However, if you wish to limit the disk space a particular user account can use, you may do so on the " Quotas " panel in the server-manager. As shown in the image below, you will see a list of user accounts, the actual disk space they are using and the quotas, if any, set for that user account.
There are two quotas that can be applied to each user account:
- Limit with grace period - when a user's disk usage exceeds this limit, an email warning message will be sent to the user account each night until the disk usage is brought back under the limit.
- Absolute limit - when a user's disk usage hits this limit, the user will no longer be able to save files to the server or receive email.
Note that if the user account exceeds the "Limit with grace period" for seven consecutive days, the account will be treated as if it exceeded the absolute limit and will no longer be able to save files or receive email.
By selecting " Modify " you are able to set a quota (in Megabytes) for a particular user account. Note that you do not have to set both limits for a user account and can choose to set only one of the limits.
If you set a limit and later wish to disable the quota for a given user account, all you need to do is set the limit to "0".
Any user who has an account on your SME Server will be able to receive email sent to that user ID. For instance, if you have a user named Fred Frog with the user account "ffrog", his primary email address will be "firstname.lastname@example.org".
Likewise, when you create a group account, that group account name functions as an email alias, so that messages addressed to the group ID will be sent to all members of the group. If, for example, you create a group called "sales", messages to "email@example.com" will be distributed automatically to all members of that group. As you add and remove members to the group, your server automatically updates the email alias.
In addition to user and group accounts, your server also automatically creates several pseudonyms . For instance, for each user account, the server creates two separate pseudonyms using the first and last names of the user. These two pseudonyms are in the form of "firstname.lastname" and "firstname_lastname". Hence, when you create the user account "ffrog" for a user with the name Fred Frog, he will also be able to receive email sent to "firstname.lastname@example.org" and "email@example.com".
Additionally, your server creates a special pseudonym called "everyone" that includes all user accounts on the system. Two other pseudonyms, "postmaster" and "mailer-daemon" are created pointing to the "admin" user.
If you wish to modify or remove any of these pseudonyms, or create new ones, you can use the web panel found under the "Collaboration" section of the server-manager, as shown below.
As noted on the screen below, there are some restrictions on the text content of the names. Pseudonyms can be linked to existing user or group accounts. In the example shown, a pseudonym for webmaster is being set to point to ffrog.
Practical usage guidelines
An SME Server has only one name set, meaning only one occurrence of a name can be in the system, whether it be a user, a group, a pseudonym or an ibay. Therefore whenever you create a user account and you have multiple domains, then that user will apply to all domains automatically.
So the user account "sales" will receive email for:
The problem with this is that you cannot have different people using the same user account name to collect email.
Using the pseudonyms panel is the only way that SME Server can distribute email for the same user "name@different-domain" names, but you need to use it in conjunction with the correct underlying naming concepts.
The golden rule is never allocate unique user names to end users accounts as these will no longer be available for globalname@domain type email address usage.
- create your domains eg domain1, domain2, domain3, domain4 and configure those domains to use different ibays for the web content. You can even setup different groups to allow only different users to access each ibay to update web content etc.
- create user accounts user1, user2, user3, user4 as needed for users who want to use the email address "sales", but keep in mind they will use the login name user1 rather than sales (the login names could be johnb, johnb2, johnw, johnm etc)
- create user accounts user5, user6, user7, user8 as needed for users who want to use the email address "info", but keep in mind they will use the login name user5 etc rather than info
- create user accounts user9, user10, user11, user12 as needed for users who want to use the email address "accounts", but keep in mind they will use the login name user9 etc rather than accounts
- create pseudonyms eg
- sales@domain1 which forwards to user1
- sales@domain2 which forwards to user2
- sales@domain3 which forwards to user3
- sales@domain4 which forwards to user4
- info@domain1 which forwards to user5
- info@domain2 which forwards to user6
- info@domain3 which forwards to user7
- info@domain4 which forwards to user8
- accounts@domain1 which forwards to user9
- accounts@domain2 which forwards to user10
- accounts@domain3 which forwards to user11
- accounts@domain4 which forwards to user12
ie. in the pseudonyms field type the whole pseudonym name as sales@domain1
Note do not use sales, info or accounts for any other purpose ie. as user account names or group names or pseudonym names (on its own) or ibay names.
If you want webmail to be configured for the correct domain for the correct end user the first time they use it, then you will need to do that manually yourself before issuing the login details to the user, eg login to webmail as the end user eg user1 (for domain1) and setup the profile for that user to show the return email address of sales@domain1 login to webmail as the end user eg user2 (for domain2) and setup the profile for that user to show the return email address of sales@domain2
Do the same for all other webmail accounts that will be issued configuring the profile and return address as applicable.
If you don't configure webmail profiles manually then they will have the default return address of loginusername@domain1 (or the main domain name of the server if different).
Summary eg For user1 for domain1
The user account will be user1 (eg johnb) and the person uses that name (& corresponding password) to login to the server or to webmail. The email address for the user will be the same as the pseudonym ie sales@domain1 and that is the address the user should publish and use as the return email address. Obviously the name before the @domain is different to their login username, that's the compromise to be accepted if using sme this way. It is quite common in practise, as users often have different "position related" pseudonyms anyway eg manager@domain1 forwards to user1.
As the user account user1 has been created on the server, then that will also work as a valid email address ie user1@domain1 will deliver email to user1, but note also that email "inadvertantly" sent to user1@domain2 or user1@domain3 or user1@domain4 will also be sent to user1. This is not usually a problem as you simply don't tell user1 that any other hosted domain addresses will work for that name.
Alternative configuration of users
If the above method is not acceptable/desirable, then the only other way you could setup users is to have only one occurrence of a user name in the system eg john, john1, john2, john3, johnb, johnb1, johnb2, johnw, johnws etc, similar to what ISP's do anyway.
Every username will be a valid (email address) for every domain hosted on your server, but you only tell the end user about their domain eg john@domain1 john2@domain1 john3@domain2 johnb@domain1 johnb2@domain2 johnb3@domain3 etc
but john@domain2 and john@domain3 etc will still work.
Any email sent to any of the addresses will automatically be received by the end user account, and the user account name and login name will be the same. There is no need to configure pseudonyms in that case.
You will still need to configure Webmail profiles manually for each domain that is different to the default domain.
The ultimate answer to having separately administered domains and identical user names at different domains, is to host only one domain on each SME Server ie have a different server for every domain. There are posts in the contribs.org forums explaining how to do this and forward/delegate email for different domains from one gateway server to other server-only boxes on the same LAN using the same Internet connection.
See this thread for details http://forums.contribs.org/index.php?topic=30953.0
Removing the default SME server behaviour to auto create pseudonyms. In this scenario (multiple domains) you may not require or desire the need of the default behaviour of auto creation of pseudonyms.
To achieve this comment with an # at beginning the line 793 into /usr/lib/perl5/site_perl/esmith/FormMagick/Panel/useraccounts.pm
the line should be like
The i-bay (information bay) feature of the SME Server is a simple, very flexible and powerful way for you to share information with others. It is such a rich and important feature that we've devoted Chapter 14 entirely to dealing with Information Bays.