4. Accounts and sign-in#

Every person who uses the server has an account. One name and password work for the desktop, Files, file sharing (SMB, SFTP), SSH and the server's console. You manage accounts in Settings > Users and Groups.

Accounts#

• Create one account, or Import many from a CSV file. The import shows a preview of what can be made, and why not.
• Edit: the full name, Administrator or Standard user, whether the account May sign in to the web desktop, its groups, and its quota on each ext4 volume with quotas on. The email address is set by the person in My Account, or by an Administrator in Settings > Security > Account (Password reset by email, Edit).
• Password sets a new password; the account can also be made to choose its own at its next sign-in.
• Rename renames the account, the first Administrator's too: its home folder, permissions, file sharing password, two-step sign-in, passkeys, API tokens, share links, email address and appearance follow. The account is signed out everywhere; programs it still runs (an SSH sign-in, for example) must end first.
• Lock / Unlock: a locked account cannot sign in anywhere, and its share links and API tokens stop working.
• Reset two-step: for someone who lost their phone and their recovery codes.
• Delete, with its home folder if you choose.

Administrators manage the server and can use sudo over SSH. Standard users use Files, the apps they are allowed, and their own account settings.

Groups#

Groups give several accounts the same access to shared folders and apps. Create a group, choose its members, and use it in a shared folder's permissions or in App Permissions. Two groups are built in: Administrators and Everyone (every account that may sign in).

Home folders#

Every account has a home folder, its own private space, shown in Files as Home. In Settings > Users and Groups > Advanced, choose where the home folders live (Keep them on): on the system disks (/home), or on a volume, where the accounts' quotas apply. On a volume, each account also reaches its own home folder over SMB, as a share with its own name (\\nas.local\anna).

Password rules and lockout#

Settings > Security > Account:

• Password rules: the minimum length and the kinds of characters needed. A password may never hold the account's name, nor be one of the most common passwords.
• Expiry: a password that must be changed after some days; the new one is chosen at sign-in. An account can also be told to choose a new password at its next sign-in.
• Account protection: Lock an account that keeps failing locks an account for some minutes after a number of failed sign-ins in a row, and lists the locked accounts, to unlock one.
• Two-step sign-in: how many days a trusted browser skips the code.
• Password reset by email: with Accounts may reset a forgotten password on, Forgot your password? on the sign-in page sends a one-time link, valid for 30 minutes, to the account's email address; an account with two-step sign-in also needs its code. It needs email in Settings > Notifications, and it answers the same way whether the name exists or not. The list below it sets each account's email address (Edit).

Settings > Desktop Access sets when a sign-in ends (idle minutes, and hours in any case), how many failed sign-ins pause an address and for how long, and whether Standard users may sign in to the desktop at all.

Two-step sign-in and passkeys#

Each person turns these on for themselves in My Account (The desktop):

• Two-step sign-in: a 6-digit code from an authenticator app after the password, with ten recovery codes. To move it to a new phone, turn it off (that asks for the password) and set it up again: while it is on, nobody can put another authenticator in its place.
• Passkeys: sign in with a phone, Windows Hello, Touch ID or a security key, without a name or a password.

Security Check reminds Administrators to turn two-step sign-in on.

Who is signed in#

Settings > Security > Signed in lists every sign-in to the desktop now, with its address, and signs one out. In Logs, the source Administrator actions lists every change made on the desktop or with the API, with who, when and from where (and the API token, if one was used). Passwords and codes are never written there.

Directory services#

Settings > Directory Services connects the server to the accounts of your organization, so people sign in with their usual name and password.

• Active Directory: join a Windows Server or Samba domain. Domain accounts sign in to the desktop and connect to shared folders over SMB with their domain password. Before joining, the server must find the domain through its DNS server, its clock must be within 5 minutes of the domain's (Settings > Language and Time), and its name must be 15 characters or fewer.
• LDAP: connect to OpenLDAP, FreeIPA, LLDAP or another LDAP server. Its certificate is always checked. LDAP accounts sign in to the desktop, Files and the apps, but not over SMB; they need POSIX attributes.

For both, you choose which directory groups may sign in and which are Administrators. The server's own accounts keep working, and a directory account whose name is also a local account's is refused. Directory accounts and groups get shared folder permissions with the API or the command line only (Shared folders: permissions). Leave the domain (or Disconnect) removes the connection; with a domain account that may remove computers, the server's computer account goes from the domain too. To make a domain of your own instead, with this server as its domain controller, use the Domain app.

Domain#

The Domain app makes this server the domain controller of your home or office: an Active Directory domain, made with Samba. Windows PCs, Macs and Linux computers join the domain. Their people sign in on every computer of the domain with one name and password, and open the server's shared folders with the same account.

Making a domain#

Open Domain, and fill in Make a domain:

• Domain name: like home.lan or ad.example.com. Not .local, which Macs use for Bonjour. It cannot change later.
• Short name: the domain's short name, 15 characters at most (people can sign in as HOME\anna).
• Its address: a free address in the server's network. The domain controller answers there; the server keeps its own address for the desktop and its shared folders.
• DNS for the rest: where the domain's DNS asks for every other name. Usually your router.
• The domain's accounts use this server's shared folders (on): the server's file server joins the domain, so the domain's people open the shared folders with their domain account. The server's own accounts keep working.

Make the domain installs Samba's domain controller and makes the domain: a few minutes, longer on a slow processor. OSM gives the domain's Administrator a password of its own: Save its password as a file (on Overview, under Settings) and keep it safe. A server that is a member of another domain (Directory services) leaves it first. When the server keeps a domain it served before, OSM asks before the new one takes its place, and copies the old one first: it stays among the copies.

Overview: checks, joining a computer, settings#

• Checks: the domain controller runs and answers on its address, its DNS finds it, the server finds the domain, the shared folders reach the domain, computers can take the time from it, its database is sound, it has a recent copy, and its certificate is valid. A check that fails has the button that repairs it.
• Join a computer: the steps for Windows, macOS and Linux, with what to type. The computer's DNS server is the domain controller's address: set it on the computer, or better, in your router's DHCP settings, so every computer gets it. Windows Home cannot join a domain.
• Settings: whether the domain's accounts use the shared folders, the DNS for the rest, and the Administrator's password (Save its password as a file, New password...).
• Maintenance: Check the database, Repair the database... (a copy of the domain is made first), Repair the rest (the service, its certificate, the shared folders' membership, the server's DNS, the time and the firewall), Restart, and Stop being the domain controller....

OSM checks the domain's database and copies the domain every night, and tells you when something is wrong.

The domain's accounts#

Accounts lists the people of the domain. Search, or Show only the accounts turned off, locked, choosing a new password at sign-in, ending within 30 days, not seen for 90 days, or the administrators.

• New account...: the first and last name, the account name (made from the names, or your own), the password (Make one makes one to give the person), and whether the person chooses their own at the first sign-in. Domain administrator puts the account in Domain Admins: every computer of the domain is theirs.
• Click an account to change it. Details: name, email, phone, job title, department, company, office. Groups: its groups. SSH keys: its public SSH keys, one per line; each one opens every Linux server of the domain for this account. Account: whether it can sign in, unlock it, a password that never expires, a new password at the next sign-in, the day the account ends, its unit, New password... and Delete....
• Import... makes many accounts from a spreadsheet saved as CSV. Its first line names the columns: name (or username), password, first name, last name, display name, email, phone, title, department, company, office, description, groups (separated by | or ;) and unit. OSM makes a password for each account without one: Save the passwords made (once) gives you the list, once (OSM forgets it after a day). The lines it could not make are listed with the reason.
• Export saves the accounts as a CSV file.

The passwords follow the domain's rules (Password rules and Group Policy). An account cannot have the name of one of this server's own accounts.

The domain's groups#

Groups give their members the same permissions, on the domain's computers and on the server's shared folders. New group...: its name, its kind (Security group, for permissions, or Email list), and its members: accounts, other groups and computers. Every account is in Domain Users; Domain Admins are the administrators of every computer of the domain. Show the domain's own groups shows the rest of Samba's built-in groups.

Computers and units#

Computers lists the PCs, Macs and servers that joined the domain, with their system, when they were last seen, and where they are on the network: On the network shows each one's address (from the domain's DNS, where computers register themselves) and whether it answers, with what (Remote Desktop, SSH, SMB). Look again asks again. Click a computer for its details: its addresses, its network card, its system, its unit. ··· opens a remote desktop or a terminal to it, Wake it up (a computer that is off, when its network card allows it: OSM remembers the card it last saw), saves a Remote desktop file (.rdp) for Windows' own Remote Desktop app, moves it to a unit, sets its description, turns it off or on, or takes it out of the domain.

Units are folders of the domain that sort its accounts, groups and computers (by site or department, for example): New unit..., Unit in it, Rename..., and Delete (the bin) for an empty one. A Group Policy object linked to a unit applies to what is in it. Accounts and groups go in Users, and computers in Computers, unless you choose a unit. Rules... sets the rules of a unit's computers.

Remote desktop#

The desktop of a Windows PC of the domain, in a window of OSM, from any browser: Computers, ··· next to the PC, Remote desktop.... The PC needs Remote Desktop on (Windows Pro, Enterprise or Education; the rules of its unit can turn it on).

• Account: a domain account (HOME\anna, or just anna), or one of the PC's own (.\name), and its password.
• Keyboard: the keyboard you type on; the PC uses its layout for the session.
• Screen: as big as the window, or a size of your own.

The first time, OSM shows the PC's certificate: Windows makes its own, so compare its thumbprint with the one the PC shows (PowerShell on the PC: Get-ChildItem Cert:\LocalMachine\"Remote Desktop"), then Trust it and connect. From then on OSM connects to that PC only with that certificate, and tells you when it changes (Windows renews its own every year, and a reinstalled PC makes a new one; but another machine posing as the PC shows another too).

The window has Ctrl+Alt+Del, Paste to the computer... (text for the PC's clipboard), Copy from the computer (what the PC copied), Full screen and Disconnect. The session ends when you close the window; the PC keeps your Windows session, as with Windows' own Remote Desktop. The first remote desktop installs FreeRDP and TigerVNC (about 400 MB).

Linux servers#

Linux servers join the domain as Windows PCs do: the domain's accounts sign in there (SSH, the console) with their own name and password, get a home folder at their first sign-in, and the rules of the server's unit decide who may sign in.

A server is closed until you open it, as Windows' own servers are. It goes into OSM's unit Linux servers (OSM makes it with the first server), whose rules let in only Domain Admins and the groups that may use sudo on its servers. Each server you add there puts its sudo groups into those rules; nothing is ever taken out of them. To let more people in, change the unit's rules (Units > Rules... next to Linux servers). If you choose Everyone in the domain there, OSM leaves it that way. If the whole domain has rules, they apply there instead.

The rules are the unit's, so a sudo group of one server may sign in on every server of the unit (sudo itself stays per server). To keep groups apart, make units inside Linux servers, one for each kind of server, with rules of their own.

1. Linux servers > Add a Linux server...: its host name, its unit (Linux servers unless you choose another), and Who may use sudo there (Domain Admins always; a group like Linux admins works at once for every member, now and later).
2. Make the join command: OSM makes the server's account with a one-time password and gives you one command. Paste it into a terminal on the server (as root, or a user with sudo), or Save the script and run it there: sudo sh join-web1.sh. The window also says who may sign in there. If the unit has no rules, it warns you that every account of the domain may.
3. The script installs sssd and adcli from the server's own distribution (Debian, Ubuntu, Fedora, RHEL and its kin, openSUSE), joins the domain, and sets up the sign-in, the home folders, sudo, SSH (Kerberos tickets and the keys kept with the accounts) and the server's name in the domain's DNS.

The page's Who may sign in column shows, for each server, who may sign in from the network (SSH): the rules that apply where it is, as the server applies them. Everyone in the domain in orange means no rule says who.

The one-time password works once: the server then keeps a password of its own. Join again... makes a new command (the server's old password stops working). The server must find the domain: its DNS server is the domain controller's address (the script sets that up itself on servers with systemd-resolved), and its clock must be right.

··· next to a server opens a Terminal (SSH)... to it: the account you name there signs in with its password or its keys. Each account's SSH keys (Accounts) open every Linux server of the domain. The first terminal installs OpenSSH's client.

Rules of a unit's computers#

Units > Rules... next to a unit (or Rules of the whole domain...) sets, for the computers in it:

• Sign-in at the computer and Sign-in from the network (Remote Desktop, SSH): everyone in the domain, or only the Administrators and the groups and accounts you choose. Windows PCs and Linux servers both follow them. The computers' Administrators and Domain Admins may always sign in.
• Remote Desktop on the Windows PCs: on, with Network Level Authentication and through the PCs' firewall, and who may use it besides the Administrators.
• Administrators of the Windows PCs: groups made members of each PC's Administrators.

Windows PCs take the rules at their next Group Policy refresh (within 90 minutes, at a restart, or at once with gpupdate /force); Linux servers at the next sign-in. A unit with rules shows Rules. OSM keeps them in a Group Policy object of its own, linked to the unit ("OSM: rules of ..."), so they come back with every copy of the domain.

Shared folders and drives#

Shared folders says what the domain's groups and accounts may open of the server's shared folders: Add... chooses a group or an account and its access (Read/Write, Read only or No access). People open them with their domain account, from a computer of the domain or any other. The server's own accounts and groups keep their permissions in Settings > Shared Folders.

Drives gives the domain's Windows PCs shared folders as drive letters at every sign-in: Add a drive... chooses the shared folder, its letter, who gets it (everyone in the domain, or one group) and its name in Windows. A PC takes a change at its next sign-in, or at once with gpupdate /force.

Both need The domain's accounts use the shared folders on.

The domain's DNS#

Computers find the domain, and each other, through the domain's DNS. DNS lists its zones and records. Add a record... adds a name (A, AAAA, CNAME, MX, TXT or SRV); Delete (the bin) deletes one. A record a computer registered itself comes back when it registers again. Show the domain's own records shows the records the domain needs: they cannot be deleted. Names of the addresses makes the reverse zone of the server's network (names for addresses). DNS for the rest is where the domain asks for every other name.

Password rules and Group Policy#

Policies:

• Passwords and sign-in: the shortest password, three kinds of characters, how many passwords are remembered, how long a password lasts, how many wrong passwords lock an account, and for how long. Recommended fills in OSM's advice. The domain controller enforces them for every account of the domain: on every computer, and for the shared folders.
• Group Policy: the domain's Group Policy objects and where they are linked. Make and edit them on a Windows PC of the domain with the Group Policy Management console (part of Microsoft's Remote Server Administration Tools), then Link to... the whole domain or a unit here.

Copies of the domain#

OSM copies the domain every night and keeps its last 7 copies on the server (the copies of a domain it served before stay until you delete them). Each backup that keeps the server's settings (Backup) holds a copy too. Copies has Copy now, Download and Delete (the bin). A copy holds the accounts' password hashes: keep a downloaded one as safe as the server.

To bring a domain back, the server is no domain controller first (Stop being the domain controller...). Then Domain offers Start it again... (the domain kept on the server), Bring it back... next to each copy, and A copy in a file... (on a USB drive or in a shared folder: a copy saved from the Domain app, or made by samba-tool domain backup). The domain comes back as it was in the copy: an account made since is not in it, and a computer that changed its password since joins again. Bring back only a copy you made or trust: it holds the whole domain, its accounts and the scripts its PCs run. OSM uses its own settings for the domain controller, never the copy's. After Restore everything... of a whole server (Backup), the copy in the backup is among them.

Stop being the domain controller#

Overview > Maintenance > Stop being the domain controller... stops the domain controller and removes its address. The computers of the domain can no longer sign their people in. With Keep the domain's database and its copies on, the domain can start again later; off, the domain is deleted from the server.

The firewall opens the domain's services (DNS, Kerberos, LDAP, SMB, time and the rest) on the domain controller's address, to your local network only. Through OSM Connect, every change in the Domain app asks for your code again (Confirm it is you), and the remote desktop and the terminal need the terminal switch on (Settings > OSM Connect).

Single sign-on for apps#

Settings > Single Sign-On lets apps sign their users in with OSM's accounts (OpenID Connect), two-step sign-in and passkeys included, with App Permissions deciding who may use each app. The page shows, for common apps, what to paste where. Many App Catalog apps can use the OSM account directly instead (Apps: how apps sign in).

App Permissions#

Settings > App Permissions allows or refuses each app for each account and group: the desktop's own apps (Files, for example) and the installed apps. Administrators may always use every app. A refused app disappears from that person's desktop, and the server refuses its operations too; an App Catalog app also refuses that person's single sign-on.