Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add required PAM rule after pam_systemd.so #2074

Merged
merged 1 commit into from
Aug 5, 2024
Merged

Add required PAM rule after pam_systemd.so #2074

merged 1 commit into from
Aug 5, 2024

Conversation

JimMadge
Copy link
Member

@JimMadge JimMadge commented Aug 2, 2024

✅ 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).

🚦 Depends on

⤴️ Summary

🌂 Related issues

Closes #2051

🔬 Tests

@JimMadge JimMadge requested a review from a team as a code owner August 2, 2024 13:08
Copy link

github-actions bot commented Aug 2, 2024

Coverage report

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

@JimMadge
Copy link
Member Author

JimMadge commented Aug 5, 2024

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
Copy link
Member Author

JimMadge commented Aug 5, 2024

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
Copy link
Member

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
Copy link
Contributor

craddm commented Aug 5, 2024

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
Copy link
Member Author

JimMadge commented Aug 5, 2024

Great @craddm 🎉

Does works absolutely fine mean,

  1. You can log in as a user in Guacamole
  2. 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 #2054 @jemrobinson ?

@craddm
Copy link
Contributor

craddm commented Aug 5, 2024

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

@jemrobinson
Copy link
Member

@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
Copy link
Contributor

craddm commented Aug 5, 2024

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
Copy link
Member Author

JimMadge commented Aug 5, 2024

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

Copy link
Contributor

@craddm craddm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@JimMadge JimMadge merged commit 2c57714 into develop Aug 5, 2024
11 checks passed
@JimMadge JimMadge deleted the skel_fix branch August 5, 2024 13:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

/etc/skel files not being applied
3 participants