Add required PAM rule after pam_systemd.so

JimMadge commented 1 month ago

:white_check_mark: Checklist

[ ] You have given your pull request a meaningful title (e.g. Enable foobar integration rather than 515 foobar).
[ ] You are targeting the appropriate branch. If you're not certain which one this is, it should be develop.
[ ] Your branch is up-to-date with the target branch (it probably was when you started, but it may have changed since then).

:vertical_traffic_light: Depends on

:arrow_heading_up: Summary

:closed_umbrella: Related issues

Closes #2051

:microscope: Tests

github-actions[bot] commented 1 month ago

Coverage report

This PR does not seem to contain any modification to coverable code.

JimMadge commented 1 month ago

The PAM configuration file looks correct

dshadmin@shm-daimyo-sre-oda-vm-workspace-01:~$ cat /etc/pam.d/common-session
#
# Updated by Ansible - 2024-08-02T15:26:32.746577
# /etc/pam.d/common-session - session-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define tasks to be performed
# at the start and end of interactive sessions.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules.  See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
session    [default=1] pam_permit.so
# here's the fallback if no module succeeds
session    requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
session    required pam_permit.so
# The pam_umask module will set the umask according to the system default in
# /etc/login.defs and user settings, solving the problem of different
# umask settings with different shells, display managers, remote sessions etc.
# See "man pam_umask".
session    optional pam_umask.so
# and here are more per-package modules (the "Additional" block)
session    required pam_unix.so
session    [success=ok default=ignore] pam_ldap.so minimum_uid=1000
session    optional pam_systemd.so
session    optional pam_mkhomedir.so skel=/etc/skel umask=0022

JimMadge commented 1 month ago

In testing, I can't see any workspaces on Guacamole when logged in with a registered user.

Ansible has run without error, so I would assume LDAP is configured correctly (at least in the same was as on develop). The deployment ran without errors so I would hope Apricot, Entra, Guac are configured correctly.

Possible problems,

LDAP config is broken
I've made a mistake in user creation/registration
Apricot bug
Guacamole isn't configured correctly

(@craddm @jemrobinson for your information)

jemrobinson commented 1 month ago

Can you check for any suspicious log output in the remote-desktop > guacamole-user-sync and identity > apricot containers? Is your user registered with the SRE? What's the output of dsh users list YOUR_SRE_NAME?

I think that the remote desktop container needs to be restarted in order to get Guacamole to read updated data from the database - this should be done as part of dsh users register but it's possible this isn't happening.

craddm commented 1 month ago

I just deployed shm-green-sre-moocow-rg from the skel_fix branch and it worked absolutely fine

daimyo is deployed against green too, right? I'm wondering if it's a mismatch with the expected values for the ldap search. An excerpt from the apricot logs:

2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37] ... group 'matt.craddock' is a member of 'CN=Primary user groups for Data Safe Haven SRE moocow Users,OU=groups,DC=daimyo,DC=develop,DC=turingsafehaven,DC=ac,DC=uk'
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37] Attempting to validate 79 groups.
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37] Attempting to validate 11 users.
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37] ... user 'aad.admin.martin.oreilly' failed validation.
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37]  -> 'domain': expected 'daimyo.develop.turingsafehaven.ac.uk' but 'green.develop.turingsafehaven.ac.uk' was provided.
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37] ... user 'aad.admin.jim.madge' failed validation.
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37]  -> 'domain': expected 'daimyo.develop.turingsafehaven.ac.uk' but 'green.develop.turingsafehaven.ac.uk' was provided.
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37] ... user 'aad.admin.matt.craddock' failed validation.
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37]  -> 'domain': expected 'daimyo.develop.turingsafehaven.ac.uk' but 'green.develop.turingsafehaven.ac.uk' was provided.
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37] ... user 'sherlock.holmes' failed validation.
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37]  -> 'domain': expected 'daimyo.develop.turingsafehaven.ac.uk' but 'green.develop.turingsafehaven.ac.uk' was provided.
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37] ... user 'james.robinson' failed validation.
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37]  -> 'domain': expected 'daimyo.develop.turingsafehaven.ac.uk' but 'green.develop.turingsafehaven.ac.uk' was provided.
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37] ... user 'grace.hopper' failed validation.
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37]  -> 'domain': expected 'daimyo.develop.turingsafehaven.ac.uk' but 'green.develop.turingsafehaven.ac.uk' was provided.
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37] ... user 'ada.lovelace' failed validation.
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37]  -> 'domain': expected 'daimyo.develop.turingsafehaven.ac.uk' but 'green.develop.turingsafehaven.ac.uk' was provided.
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37] ... user 'jim.madge' failed validation.
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37]  -> 'domain': expected 'daimyo.develop.turingsafehaven.ac.uk' but 'green.develop.turingsafehaven.ac.uk' was provided.
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37] ... user 'entra.admin.emergency.access' failed validation.
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37]  -> 'domain': expected 'daimyo.develop.turingsafehaven.ac.uk' but 'dshdevelopgreen.onmicrosoft.com' was provided.
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37] ... user 'entra.admin.james.robinson' failed validation.
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37]  -> 'domain': expected 'daimyo.develop.turingsafehaven.ac.uk' but 'dshdevelopgreen.onmicrosoft.com' was provided.
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37] ... user 'matt.craddock' failed validation.
2024-08-05 10:13:11+0000 [ReadOnlyLDAPServer,97,10.0.1.37]  -> 'domain': expected 'daimyo.develop.turingsafehaven.ac.uk' but 'green.develop.turingsafehaven.ac.uk' was provided.

JimMadge commented 1 month ago

Great @craddm :tada:

Does works absolutely fine mean,

You can log in as a user in Guacamole
The skeleton files are written to a users home directory when logging in for the first time using LDAP

Oh, could that be related to the changes in https://github.com/alan-turing-institute/data-safe-haven/pull/2054 @jemrobinson ?

craddm commented 1 month ago

Yes, confirm both: I can login as a Guacamole user, and the contents of /etc/skel are copied to the home directory

jemrobinson commented 1 month ago

@JimMadge : If your user doesn't belong to the correct domain for your SHM then yes, #2054 will mean that they don't show up in the identity server. Hard to be sure without some more information (e.g. the logs I asked for above).

craddm commented 1 month ago

Added a new user to moocow, guacamole-user-sync logs say:

, [2024-08-05T10:52:23.386039 #1603]  INFO -- : found pg-user: "matt.craddock@green.develop.turingsafehaven.ac.uk"
I, [2024-08-05T10:52:23.391381 #1603]  INFO -- : found pg-group: "Data Safe Haven SRE moocow Administrators" with members: []
I, [2024-08-05T10:52:23.392867 #1603]  INFO -- : found pg-group: "Data Safe Haven SRE moocow Privileged Users" with members: []
I, [2024-08-05T10:52:23.394513 #1603]  INFO -- : found pg-group: "Data Safe Haven SRE moocow Users" with members: ["matt.craddock@green.develop.turingsafehaven.ac.uk"]
I, [2024-08-05T10:52:23.397288 #1603]  INFO -- : found pg-group: "matt.craddock" with members: ["matt.craddock@green.develop.turingsafehaven.ac.uk"]
D, [2024-08-05T10:52:23.397349 #1603] DEBUG -- : keep user: matt.craddock@green.develop.turingsafehaven.ac.uk
D, [2024-08-05T10:52:23.397362 #1603] DEBUG -- : create user: sherlock.holmes@green.develop.turingsafehaven.ac.uk
I, [2024-08-05T10:52:23.397377 #1603]  INFO -- : user stat: create: 1 drop: 0 keep: 1
D, [2024-08-05T10:52:23.397402 #1603] DEBUG -- : keep group: matt.craddock
D, [2024-08-05T10:52:23.397410 #1603] DEBUG -- : create group: sherlock.holmes
D, [2024-08-05T10:52:23.397418 #1603] DEBUG -- : keep group: Data Safe Haven SRE moocow Users
D, [2024-08-05T10:52:23.397425 #1603] DEBUG -- : keep group: Data Safe Haven SRE moocow Privileged Users
D, [2024-08-05T10:52:23.397432 #1603] DEBUG -- : keep group: Data Safe Haven SRE moocow Administrators
I, [2024-08-05T10:52:23.397441 #1603]  INFO -- : group stat: create: 1 drop: 0 keep: 4
D, [2024-08-05T10:52:23.397553 #1603] DEBUG -- : keep matt.craddock to matt.craddock@green.develop.turingsafehaven.ac.uk
D, [2024-08-05T10:52:23.397567 #1603] DEBUG -- : keep Data Safe Haven SRE moocow Users to matt.craddock@green.develop.turingsafehaven.ac.uk
D, [2024-08-05T10:52:23.397575 #1603] DEBUG -- : grant sherlock.holmes to sherlock.holmes@green.develop.turingsafehaven.ac.uk
D, [2024-08-05T10:52:23.397583 #1603] DEBUG -- : grant Data Safe Haven SRE moocow Users to sherlock.holmes@green.develop.turingsafehaven.ac.uk
I, [2024-08-05T10:52:23.397594 #1603]  INFO -- : membership stat: grant: 2 revoke: 0 keep: 2
I, [2024-08-05T10:52:23.397624 #1603]  INFO -- : SQL: CREATE ROLE "sherlock.holmes" NOLOGIN IN ROLE ldap_groups
I, [2024-08-05T10:52:23.402440 #1603]  INFO -- : SQL: CREATE ROLE "sherlock.holmes@green.develop.turingsafehaven.ac.uk" LOGIN IN ROLE ldap_users
I, [2024-08-05T10:52:23.407712 #1603]  INFO -- : SQL: GRANT "sherlock.holmes" TO "sherlock.holmes@green.develop.turingsafehaven.ac.uk" 
I, [2024-08-05T10:52:23.410776 #1603]  INFO -- : SQL: GRANT "Data Safe Haven SRE moocow Users" TO "sherlock.holmes@green.develop.turingsafehaven.ac.uk" 
2024-08-05T10:52:23+00:00 Updating database...

I added a new user to oda directly on green (via the portal):

I, [2024-08-05T10:31:34.246256 #3512]  INFO -- : found pg-group: "Data Safe Haven SRE oda Administrators" with members: []
I, [2024-08-05T10:31:34.247716 #3512]  INFO -- : found pg-group: "Data Safe Haven SRE oda Privileged Users" with members: []
I, [2024-08-05T10:31:34.249342 #3512]  INFO -- : found pg-group: "Data Safe Haven SRE oda Users" with members: []
I, [2024-08-05T10:31:34.250912 #3512]  INFO -- : found pg-group: "jim.madge" with members: []
I, [2024-08-05T10:31:34.250945 #3512]  INFO -- : user stat: create: 0 drop: 0 keep: 0
D, [2024-08-05T10:31:34.251013 #3512] DEBUG -- : create group: matt.craddock
D, [2024-08-05T10:31:34.251024 #3512] DEBUG -- : keep group: jim.madge
D, [2024-08-05T10:31:34.251030 #3512] DEBUG -- : keep group: Data Safe Haven SRE oda Users
D, [2024-08-05T10:31:34.251036 #3512] DEBUG -- : keep group: Data Safe Haven SRE oda Privileged Users
D, [2024-08-05T10:31:34.251041 #3512] DEBUG -- : keep group: Data Safe Haven SRE oda Administrators
I, [2024-08-05T10:31:34.251050 #3512]  INFO -- : group stat: create: 1 drop: 0 keep: 4
W, [2024-08-05T10:31:34.251082 #3512]  WARN -- : ldap member with dn CN=matt.craddock,OU=users,DC=daimyo,DC=develop,DC=turingsafehaven,DC=ac,DC=uk is unknown
W, [2024-08-05T10:31:34.251091 #3512]  WARN -- : ldap member with dn CN=jim.madge,OU=users,DC=daimyo,DC=develop,DC=turingsafehaven,DC=ac,DC=uk is unknown
W, [2024-08-05T10:31:34.251100 #3512]  WARN -- : ldap member with dn CN=matt.craddock,OU=users,DC=daimyo,DC=develop,DC=turingsafehaven,DC=ac,DC=uk is unknown
W, [2024-08-05T10:31:34.251107 #3512]  WARN -- : ldap member with dn CN=jim.madge,OU=users,DC=daimyo,DC=develop,DC=turingsafehaven,DC=ac,DC=uk is unknown
I, [2024-08-05T10:31:34.251126 #3512]  INFO -- : membership stat: grant: 0 revoke: 0 keep: 0
I, [2024-08-05T10:31:34.251150 #3512]  INFO -- : SQL: CREATE ROLE "matt.craddock" NOLOGIN IN ROLE ldap_groups
2024-08-05T10:31:34+00:00 Updating database...

Bunch of WARNs there, and then the user never gets LOGIN IN ROLE ldap_users

JimMadge commented 1 month ago

@craddm It seems to be working then, could you review?

alan-turing-institute / data-safe-haven