Category Archives: 04 – Users & Security

000NCL, 04 - Users & Security

Audit Logs

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud Audit Logs.

If you’ve ever needed to know who accessed a file, when a share was created, or whether someone’s been logging in at unusual hours, audit logs are your answer. Nextcloud Audit Logs track all user actions across the platform — file access, edits, shares, permission changes, and logins. For an organisation like NZRT, they’re essential for compliance, security monitoring, and forensic investigations when something goes wrong.

Let’s start with what actually gets logged. There are five main categories of events. First, file operations — that’s any time a file is created, edited, deleted, moved, or copied. Second, sharing events — when a share is created, when permissions on that share change, or when a share link expires. Third, user actions — things like logging in, logging out, changing a password, or setting up two-factor authentication. Fourth, admin actions — creating users, assigning someone to a group, or installing an app. And fifth, security events — failed login attempts, blocked shares, and any unauthorized access attempts. Together, that’s a comprehensive picture of everything happening inside your Nextcloud instance.

Now, how do you actually get to these logs? There are two ways. The first is through the web interface. You go into Settings, then Logging, and you’ll see the last hundred entries right there on screen — no extra tools needed, great for a quick check. The second way is to go directly to the log file on the server. That file lives at a path on the server’s file system, inside the Nextcloud data directory, and it’s called nextcloud.log. If you need to do any serious analysis — searching, filtering, exporting — you’ll want to pull that file directly rather than browsing through the web UI.

Next up is log retention. In Nextcloud’s configuration file, there are two key settings you should know about. The first controls how large the log file can get before it rotates — at NZRT, that’s set to ten megabytes. Once the log hits that size, it starts a fresh file so things don’t spiral out of control. The second setting just tells Nextcloud where to write the log file in the first place, pointing it to that same nextcloud.log location we mentioned. On top of that, logs older than ninety days are archived. That’s not arbitrary — it aligns with GDPR data minimisation principles, meaning you’re keeping what you need for a reasonable period and not holding onto personal data longer than necessary.

Now let’s talk about how NZRT specifically uses compliance monitoring, because different roles have different responsibilities here. There are four roles with distinct monitoring duties. Starting with xc — that’s the administrator — who monitors all actions across the board and gets alerted to things like bulk file deletions or mass sharing events, which could indicate either a mistake or something more serious. Then there’s fin, who focuses on data exports and share activity, with specific alerts for things like exported invoices or new shares being created — important for financial audit trails. Next is han, whose alerts are focused on HR-related activity: access to the HR folder and logins happening outside of office hours, which could signal unauthorized access. Finally, there’s ema, who watches for document changes — specifically anything that looks like an unapproved sync with Dolibarr, NZRT’s ERP system.

So why does all of this matter in the NZRT context specifically? There are three main compliance areas these logs support. First, Dolibarr EDM compliance — that’s electronic document management — where you need a clear record of who touched which documents and when. Second, HR record confidentiality, because personnel files need to be kept private and audit logs give you proof of who accessed them. And third, financial audit trails, so that any time financial data is exported or shared, there’s a record to point to. The person responsible for archiving and analysing logs at NZRT is dan, who holds the DBA role and steps in when there’s a security incident that needs investigation.

Pulling it all together, audit logs aren’t just a nice-to-have. They’re what lets you answer the hard questions after the fact — who did what, when, and from where. Whether it’s a compliance review, a security incident, or just wanting confidence that sensitive data is being handled correctly, Nextcloud Audit Logs give you the visibility you need. If you want to go deeper, the related wiki pages on Users and Groups, Logging and Monitoring, and Permissions and Sharing are worth reading alongside this one.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

000NCL, 04 - Users & Security

Ldap Sso

Welcome to the NZRT Wiki Podcast. Today we’re looking at LDAP and SSO.

If you’ve ever wondered how a company manages logins across multiple systems without asking staff to juggle half a dozen different passwords, LDAP and Single Sign-On are the answer. Let’s walk through how NZRT uses these technologies to connect Nextcloud, Dolibarr, and WordPress under one unified identity system.

First, let’s cover what LDAP actually is. LDAP stands for Lightweight Directory Access Protocol. Think of it as a central address book for your organisation. It stores user accounts, passwords, and group memberships in one place. That central store is usually either Active Directory, which is Microsoft’s directory service, or OpenLDAP, which is the open-source equivalent. When Nextcloud is connected to LDAP, it doesn’t manage its own user accounts — it asks the directory instead.

So how do you get that connection set up? The first step is enabling the LDAP app inside Nextcloud. There’s a command you run on the server to activate it, and once that’s done you head into the Settings area and look for the LDAP or Active Directory section. From there you configure a handful of key details. You tell Nextcloud the address of your LDAP server — in NZRT’s case that’s an internal address on the local network. You give it what’s called a Base Distinguished Name, which is the root of your directory tree, essentially your organisation’s domain broken into components. You also provide a Bind account — a dedicated service account Nextcloud uses to authenticate with the directory — and then you point it at where your users and groups live within that directory structure.

Now let’s talk about SSO, or Single Sign-On. This is what makes the experience seamless for your users. Once LDAP is connected, a user logs in once and that credential works across all integrated systems. For more advanced setups — say you’re connecting multiple identity providers or need enterprise-grade federation — there’s also a SAML option. SAML is a standard for exchanging authentication data between systems. Enabling that app and pointing it at your SAML metadata in the Security settings gets you there, but for most NZRT scenarios the core LDAP integration handles the heavy lifting.

One thing worth understanding is how groups flow across the integration. In your LDAP directory, groups have names like admin, sales, finance, and HR. When those groups sync into Nextcloud, they map directly to matching Nextcloud groups with the same names. Your admin group in Active Directory becomes the admin group in Nextcloud. Your finance team in Active Directory becomes the finance group in Nextcloud, and so on for sales and HR. You don’t have to manually rebuild your organisational structure inside each application — it comes across automatically.

Now let’s look at why this actually matters in practice. There are four key benefits. The first is a single password. When a user changes their LDAP or Active Directory password, that change flows through everywhere. They don’t need to update it separately in Nextcloud, Dolibarr, or WordPress. The second benefit is automated provisioning. When IT creates a new Active Directory account for a new hire, Nextcloud automatically picks that up and creates the corresponding user account — no manual steps needed. Third is deprovisioning. If someone leaves the organisation and IT disables their Active Directory account, their Nextcloud access is removed at the same time. You’re not relying on someone remembering to go into three different systems and disable the account manually. And fourth is group sync, which we already covered — your organisational structure stays consistent across every platform without extra effort.

For NZRT specifically, this integration spans Nextcloud, Dolibarr, and WordPress. The practical workflow is simple. When someone joins the team, IT creates one Active Directory account. From that single action, LDAP automatically syncs the user across all three systems. When they leave, one account gets disabled and access is revoked everywhere. That’s the power of centralised identity management — less administration overhead, fewer security gaps, and a much better experience for your users.

If you want to explore related topics, this wiki page connects to the Users and Groups documentation, the Two Factor Authentication guide, and the Dolibarr Integration notes.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

000NCL, 04 - Users & Security

Permissions Sharing

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud Permissions & Sharing.

If you’ve ever wondered how NZRT controls who can see what inside Nextcloud, this episode walks you through exactly that. Permissions in Nextcloud are what keep sensitive documents safe, making sure that the Finance team’s payroll data isn’t visible to Sales, and that HR records stay strictly internal. That separation is achieved through a system of folder-level access controls, which we call ACLs, or access control lists.

Let’s start with the four permission levels you’ll encounter. The first is Read. When you have Read access, you can view a file but you can’t change it, delete it, or share it with anyone else. This is the right level for things like archives or finalised documents you just need to reference. The second level is Edit. Edit access adds the ability to make changes to files on top of viewing them, which makes it the go-to level for anything that involves collaborative work. Third is Create, which lets you add new draft documents to a folder. And finally, there’s Manage. Manage is the highest level — it combines viewing, editing, deleting, and sharing all in one, and it’s typically held by whoever owns the folder or the team responsible for it.

Now let’s talk about how those permission levels are actually applied across NZRT’s folder structure. There are five key folders to know about, and each one has its own owner, read access list, edit access, and manage rights.

The Finance folder is owned by fin, which is the Finance agent. Both fin and xc can read it. Only fin can edit it. And xc holds Manage rights, meaning xc can audit and control access at the top level. The HR folder works similarly — it’s owned by han, the HR agent, with han and xc having read access, han holding edit rights, and xc managing it overall.

Sales is owned by cas, the CAS agent. Both cas and pam can read it, cas can edit, and again xc manages. The Shared Templates folder, owned by ema, is the most open of the bunch — all users can read from it, ema can edit it, and xc manages it. Finally, the Dolibarr EDM folder is also owned by ema, with read access limited to ema and xc, edit belonging to ema, and xc in the Manage seat.

So the pattern you’ll notice is that xc, the admin account, holds Manage rights across the board. This is deliberate — it gives xc the ability to audit access logs and adjust permissions without getting in the way of day-to-day work by individual teams.

Now, how do you actually set these permissions? There are two ways. The first is through the Nextcloud graphical interface. You right-click on a folder, go to Sharing, and then open Advanced settings. That’s the quickest route for one-off changes. The second way is through the command line, using Nextcloud’s built-in tool called occ. With occ you can do things like transfer ownership of a folder from one user to another. You can also add a group to a folder and assign it a specific numeric permission code. For example, adding the Finance group to the Sales folder with read and write access combined uses the number thirty-one, because permissions in Nextcloud are represented as numbers that add up depending on what you want to allow. You don’t need to memorise those numbers day-to-day, but it’s good to know that the CLI method is there when you need to make bulk or scripted changes.

The third area covered in this wiki page is public sharing — the ability to generate a link you can send to someone outside NZRT. Public sharing is selectively enabled across folders. Sales links and Finance vendor portal links can be shared publicly, because those involve external clients and partners. But HR is internal only, so no public links there, and Finance invoices are restricted to named user shares rather than open links.

When public sharing is enabled, two policies apply. Every external share must have a password — no exceptions. And every share has an expiry date, set somewhere between seven and thirty days depending on the document type. This limits the window of exposure if a link ends up in the wrong hands.

To pull everything together: permissions in Nextcloud exist to create data isolation. Finance can’t browse HR payroll. Sales can’t see Procurement cost data. The ema role is responsible for managing folder hierarchies and the EDM structure, while xc retains oversight through Manage rights and access log auditing. If you need to go deeper, the related topics to check out are Users and Groups, File Sharing and Links, and Audit Logs.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

000NCL, 04 - Users & Security

Two Factor Auth

Welcome to the NZRT Wiki Podcast. Today we’re looking at Two Factor Auth.

So, what is two-factor authentication, and why does it matter for NZRT? At its core, two-factor auth, or 2FA, means that when you log in to Nextcloud, you don’t just enter your password and walk straight in. You also need to prove your identity a second way. That second step is what makes it so much harder for someone to get into an account even if they’ve somehow got hold of your password.

NZRT supports a few different ways to do that second step, so let’s run through them. There are three methods available.

The first is TOTP, which stands for Time-based One-Time Password. You set it up by scanning a QR code, and from that point on you use an app on your phone like Google Authenticator or Authy to generate a six-digit code whenever you log in. This is the recommended method for most NZRT users.

The second method is Backup Codes. When you set up 2FA, Nextcloud generates ten single-use codes for you. These are for the situation where you’ve lost your phone or can’t access your authenticator app. Generating and securely storing these backup codes is mandatory for everyone using 2FA, not optional.

The third method is FIDO2, which uses a physical USB security key. You plug it in and touch it to authenticate. This one is optional and at NZRT it’s currently only in use by the xc account.

Now, how does NZRT actually enforce 2FA for people who need it? Through the Nextcloud admin settings, under the Security section, an administrator can turn on enforcement for specific groups. At NZRT that means the admin group, the finance group, and the HR group. When enforcement is switched on, anyone in those groups sees a prompt to set up 2FA the next time they log in. There’s also a grace period of seven days, which gives users a window to get it configured before they’re locked out of their workflow.

Let’s walk through what the TOTP setup actually looks like from a user’s perspective. First, you head into your Account Settings and enable 2FA. Nextcloud then shows you a QR code. You open Google Authenticator or Authy on your phone and scan that code. The app will immediately start showing you a six-digit number that changes every thirty seconds. You type that number into Nextcloud to confirm the link worked. Then, crucially, you save your backup codes somewhere safe, a password manager or a secure printed copy somewhere offline. From that point on, every time you log in you’ll enter your password as usual, and then you’ll be asked for the current six-digit code from your app.

So who at NZRT actually needs to do this? The policy splits into three tiers. Two-factor auth is mandatory for three accounts: xc, which is the admin account; fin, the finance role; and han, the HR role. It’s strongly recommended for two more: ema, who handles email and digital marketing, and dan, the database administrator. For everyone else in the organisation, 2FA is optional but still a good idea.

Why are finance and HR singled out as mandatory rather than just recommended? Because those roles handle sensitive personal and financial data. Data protection regulations require that access to that kind of information is properly secured, and relying on a password alone doesn’t meet that bar. If a credential gets compromised, whether through a phishing email, a reused password, or a data breach somewhere else, 2FA is the thing that stops an attacker from just walking in. The second factor, the code on your phone or the key you have to physically touch, is something an attacker very rarely has even when they have your password.

The broader point here is that 2FA isn’t about distrust of users. It’s about recognising that passwords alone are no longer a reliable defence. Credential compromise is one of the most common causes of account breaches, and adding that second step dramatically reduces the risk for the accounts that matter most.

If you’re in one of the mandatory groups and you haven’t set this up yet, now is the time. Head into your Nextcloud account settings, find the security section, and follow the TOTP setup steps. Make sure you save those backup codes. And if you have any questions, check the related notes in the wiki covering Users and Groups, Permissions and Sharing, and the Administration Overview.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.