Authentication, Access and Accounts

Management of accounts

Creating Accounts

• Usernames and passwords should be randomly generated

• Username must not be 'Administrator', 'root', 'Admin' etc unless the application forces it

• Where possible, OpenID should be configured using the AGG / XFGN OAuth Client

  • Enable AutoLogon where possible

• For services behind CloudFlare authentication, local auth can be disabled

• Where possible, use SSH keys

• If a server has public facing SSH (such as a VPS), use SSH keys and disable password sign in

Storage of account details

• Usernames, passwords, TOPT and backup codes to be saved in our Password Vault

• Internal services (eg docker containers) are to be saved in the 'Internal Services' folder, whilst external services (eg Cloudflare login, Namecheap login) are saved in the 'External Services' folder.

Deletion of Accounts

• Credentials to be tested and confirmed working, then saved in Bitwarden before deletion

Why?

This is to ensure that accounts are hard to breach and are backed up and stored appropriately. Bitwarden has a function to notify admins of any credential breaches.

---

User Permissions

• Accounts required for integrations between systems (eg Home Assistant monitoring UniFi) must first be created as read-only

• Administrator access to be granted as last ditch

  • Do NOT create new accounts as administrators

  • Log in with new account and test before granting additional access

  • Research app online to figure out what access is required if more is required

  • Administrator access can be granted ONLY IF required

Why?

This is to ensure that if accounts are breached, they can't do much damage

---

Cloudflare Authentication

I have 4 primary authentication policies configured in Cloudflare. We mostly use the 'Allow' and 'Bypass' rule

	Allow	Allow with Reason	Allow with Approval	Bypass
Explanation	User authentication. Allows access. Can be limited to country	User authentication. Allows access by requires a reason. Can be limited to country	User authentication. Allows access by requires approval from a second user. Can be limited to country	Bypasses authentication prompt. Must be applied to IP addresses, subnets or countries
Example	I need to send a WOL packet to a server	A server is off and I'm unable to send the WOL packet. This allows a second person to do that work though it is not normally within scope of their duties.	A server is off and I'm unable to send the WOL packet. This allows a second, non-technical person, to request access, be approved by myself or someone else and process this.	Allow everyone in Australia to have access to service A, but accessing outside of Australia follows one of the above rules instead
Documentation	None	Written for a technical person	Written for a non-technical person	None

Authentication in front of Logon pages

If a public facing service has a login page that shouldn't be publicly accessible, you can put the authentication in front of the URL for the login page. Eg, myapp.mydomain.com/login

Why?

This enables a consistent approach and easy to understand workflow.