Grundsätzliche Fragen zu Gruppen am Linuxclient

Hallo,
ich hatte diese Frage schon mal gestellt, das war aber off-topic in einem anderen Thema, daher jetzt nochmal richtig.

Es geht um den Linux-Client (in meinem Fall Kubuntu 18.04, mit client-adsso in Linuxmuster eingebunden), der unter der Serverversion v7 läuft. So, wie ich es verstanden habe, haben sich die Anmeldemechanismen im Vergleich zur v6 komplett geändert, die „alten“ Erkenntnisse bringen hier also nichts.
Ich wüsste sehr gerne, wo und an welcher Stelle in den Anmeldeskripten die Gruppenzugehörigkeiten für die Domänennutzer festgelegt werden.

Ganz konkret wüsste ich gerne, wie ich einen Nutzer beim Anmelden zu einer bestimmten lokal auf dem Client vorhandenen Unix-Gruppe hinzufügen kann (das ist die Gruppe „dialout“).

Ferner wüsste ich gerne, ob es auf den mit client-adsso eingebundenen Clients zwei Arten von Gruppen gibt. Gebe ich auf der Konsole
„groups“
ein, so wird mir als Domänennutzer z.B. die Gruppe „teachers“ angezeigt.

Starte ich aber als lokaler Nutzer ein Tool wie veyon , wo unix-Gruppen eine Rolle spielen, so wird mir die Gruppe „teachers“ gar nicht angezeigt.

Ist „teachers“ sozusagen eine Gruppe, die sich der „groups“ Befehl vom AD-Server holt? Wo kann ich darüber etwas nachlesen? Oder irre ich mich hier total, und die Gruppe „teachers“ ist eine lokal angelegte unix-Gruppe?

Vermutlich habe ich mich sehr unklar ausgedrückt, vielleicht kann mir trotzdem jemand etwas erklären, das wäre sehr hilfreich.
Gruß Andreas

Hi nochmal,

ich kann ja eigene Anmeldeskripte unter

/etc/linuxmuster-client/login.d

hinzufügen. Die nützen mir aber nichts, weil sie mit User-Rechten laufen.

Ich bräuchte also irgend ein Skript (oder einen Ort, wo ich es hintun kann), das mit root-Rechten läuft, und wo ich den Nutzer beim Anmelden in die (lokale) gruppe „dialout“ reintun kann.

Oder, noch konkreter:

#!/bin/bash
`usermod -a -G dialout $USER_DER_SICH_GERADE_EINLOGGT`

Wo kann ich das hintun, und wie lautet die Variable, wo der User, der sich grade einloggt, drinsteht?

Dank + Gruß,
Andreas

Hallo Andreas,

… kann man nicht alle der Gruppe dialout zuordnen?
Frag mal duckduckgo danach…

Oder, noch konkreter:

#!/bin/bash usermod -a -G dialout $USER_DER_SICH_GERADE_EINLOGGT |

usermod in die sudoers rein mit ALL:ALL?

LG

Holger

Hallo,

    #!/bin/bash |usermod -a -G dialout $USER_DER_SICH_GERADE_EINLOGGT| |

usermod in die sudoers rein mit ALL:ALL?

… das ist eher doch keine gute Idee …

LG

Holger

Das Problem ist, dass das Domänenuser sind.

Normalerweise könnte man das mit der

/etc/adduser.conf

erledigen, da kann man reinschreiben, in welche Gruppen neue User standardmäßig reinkommen.

Die Domänenuser sind aber keine „neuen“ User in diesem Sinne.

Ich habe hier schon danach gesucht, in der 6.2 gab es wohl eine config-Datei, wo man reinschreiben konnte, in welche Gruppen Domänenuser rein sollen, für die 7.0 habe ich das aber noch nicht gefunden.

Hintergrund ist, dass Domänenuser jetzt weder einen Legoroboter programmieren können noch einen Arduino ansteuern können, weil man dafür in der dialout - Gruppe sein muss!

Vielleicht meldet sich hier noch jemand von den Entwicklern des client-adsso , die wissen sicher, wo man das reinschreiben könnte. Ich habe jedenfalls keine Ahnung.

Hallo Andreas,

unter der 6.2 war das die Datei /etc/security/group.conf in der man regeln konnte, in welche Gruppen ein user (egal ob Domänenuser oder lokaler User) beim Anmelden am Client gesteckt wird. Geregelt wird das über pam bei der Anmeldung. Das funktioniert bei mir in der 7 immer noch.

Hier meine group.conf. Die entscheidende Zeile ist die, die mit *;*;*;AL... anfängt; hier werden die Gruppenzugehörigkeiten für alle sich anmeldenden user festgelegt. Darunter dann die Gruppenzugehörigkeit speziell für den global-admin.

##
## Note, to get this to work as it is currently typed you need
##
## 1. to run an application as root
## 2. add the following groups to the /etc/group file:
##		floppy, games, sound
##
#
# *** Please note that giving group membership on a session basis is
# *** NOT inherently secure. If a user can create an executable that
# *** is setgid a group that they are infrequently given membership
# *** of, they can basically obtain group membership any time they
# *** like. Example: games are allowed between the hours of 6pm and 6am
# *** user joe logs in at 7pm writes a small C-program toplay.c that
# *** invokes their favorite shell, compiles it and does
# *** "chgrp games toplay; chmod g+s toplay". They are basically able
# *** to play games any time... You have been warned. AGM
#
# this is an example configuration file for the pam_group module. Its
# syntax is based on that of the pam_time module and (at some point in
# the distant past was inspired by the 'shadow' package)
#
# the syntax of the lines is as follows:
#
#       services;ttys;users;times;groups
#
# white space is ignored and lines maybe extended with '\\n' (escaped
# newlines). From reading these comments, it is clear that
# text following a '#' is ignored to the end of the line.
#
# the first four fields are described in the pam_time directory.
# The only difference for these is how the time field is interpretted:
# it is used to indicate "when" these groups are to be given to the user.
#
# groups
#	The (comma or space separated) list of groups that the user 
#	inherits membership of. These groups are added if the previous
#	fields are satisfied by the user's request
#

#
# Here is a simple example: running 'xsh' on tty* (any ttyXXX device),
# the user 'us' is given access to the floppy (through membership of
# the floppy group)
#

#xsh;tty*&!ttyp*;us;Al0000-2400;floppy
# another example: running 'xsh' on tty* (any ttyXXX device),
# the user 'sword' is given access to games (through membership of
# the sound and play group) after work hours.  (The games group owns
# high-score files and so on, so don't ever give users access to it.)
#

#xsh; tty* ;sword;!Wk0900-1800;sound, play
#xsh; tty* ;*;Al0900-1800;floppy

*;*;*;Al0000-2400;dialout,cdrom,floppy,audio,dip,video,plugdev,scanner,vboxusers
*;*;global-admin;Al0000-2400;adm,admin,lpadmin

#
# End of group.conf file
#

So sollte das bei dir eigentlich auch klappen.

VG

Dominik

Hallo Andreas,

unterhalb von /etc/linuxmuster-client gibt es einen Ordner so ähnlich wie pre-mount oder post-mount, die Skripte darin werden alle als root ausgeführt.

Beste Grüße

Jörg

Hallo Dominik,
herzlichen Dank - aber es klappt nicht. Ich habe bisher nach Internetrecherche nur so viel verstanden, dass dieses pam-Modul gar nicht unter allen Umständen ausgeführt wird und somit /etc/security/group.conf teilweise gar nicht zur Geltung kommt.

Ich habe das auf einem Client ausprobiert, der hier rumsteht, ich bin aber gerade nicht in der Domäne. Es geht aber nicht mit gecachten Usern, und es geht auch nicht mit lokalen Usern (auch nicht mit einem, den ich frisch angelegt habe).

Ich meine mich auch dahingehend zu erinnern, das schon mal probiert zu haben, jedenfalls hatte ich von /etc/security/group.conf schon mal was gehört.

Hast Du einen tipp für mich, wie ich das System dazu kriege, diese Datei auch abzuarbeiten? Scheint bei mir, wie gesagt, keinerlei Wirkung zu haben.
Vielen Dank,
Andreas

Ich präzisiere: Es klappt nicht mit kde konsole (von mir getestet) und mit der gnome-Konsole, siehe hier:

https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1762391

Wenn ich mich auf tty einlogge, dann geht’s.

In den kommentaren zu dem Bugreport steht, dass man das modul wohl besser nicht mehr verwenden sollte. Ich weiß jetzt nicht, ob unter KDE dann die Gruppenzugehörigkeit nur innerhalb der Konsole fehlt, oder ob der User die auch „auf dem Desktop“ nicht hat.

Ich müsste das dann konkret irgendwie testen, fürchte aber, dass es so nicht geht.

Also bleibt die Frage offen: Wie bekomme ich einen LInuxmuster-Domänenuser so in eine lokale Gruppe rein, dass es auch mit KDE und Gnome geht?

Workaround könnte sein, dass ich xterm installiere und man dann die (wenigen) Programme vom xterm aus aufruft, für die man das braucht, ich schaue mal.
Edit: mit xterm geht es auch nicht.

Also: wenn ich mich auf tty einlogge, dann hat der user die Gruppen, die in /etc/security/group.conf stehen, wenn ich einen grafischen Login mache, dann nicht. Seufz.

@jrichter : Eine solche Datei / Ordner gibt es auf meinen Clients leider nicht. Pre-Mount / Post-Mount klingt aber nicht so, als wäre es teil des Loginprozesses, sodass man da vermutlich nicht auf einen bestimmten User zugreifen kann (um etwa ein groupadd durchzuführen).
Gruß, Andreas

Jedenfalls scheint das allgemein schwierig zu sein:

https://forum.ubuntuusers.de/topic/sddm-pam-konfiguration/#post-7633548

Wer nochmal das Ausgangsproblem wissen will: Ich will alle User in den Gruppen dialout und lego haben. Sonst funktionieren Arduino + Lego-Roboter nicht.

Falls es irgend einen anderen Trick gibt - etwa, dass die User der Gruppe domain, oder users (wo die Domänenuser ja alle drin sind) automatisch die Rechte der Gruppe dialout + lego haben, dann soll mir das alles recht sein.

Momentan habe ich einen lokal auf dem client angelegten User, der dann Arduino + Lego benutzen kann,a ber das ist sehr lästig, weil der dann ja kein Netzwerk hat.

Hallo Andreas,

Sorry für die Verwirrung - bei meinem Mailer kam das v7 nicht an, die Antwort gilt für v6.

Beste Grüße

Jörg

Guten Morgen,
wenn keiner mehr eine Idee hat, werde ich vermutlich so vorgehen:

Da wird erklärt, wie man mit Hilfe einer UDEV Rule jedem beliebigen Nutzer den Zugriff auf den seriellen Port erlaubt.

Da ich aber das Gefühl habe, dass mir die Sache mit den Gruppenzugehörigkeiten noch öfter auf die Füße fallen wird, wäre ich sehr froh, wenn jemand das mit den Gruppenzugehörigkeiten klären könnte. Vielleicht frage ich mal auf Github nach - oder hat hier jemand Kontakt zu den Entwicklern des client-adsso? Die Domänenuser sind ja auch in anderen Gruppen drin, das muss also irgendwie gehen, und es steht vermutlich irgendwo im client-adsso.

Gruß, Andreas

Ein paar Versuche habe ich noch gemacht.

  1. Versuch: Das client-adsso mit grep durchforstet nach group - Sachen. Nichts passendes gefunden.

  2. Internetrecherche (das Problem ist häufiger anzutreffen und hat nicht direkt mit Linuxmuster zu tun, sondern ist überall dort relevant, wo man sich an AD authentifiziert) und DAS gefunden (vorsicht, gefährlich):
    https://www.reddit.com/r/linuxadmin/comments/aaa0so/sssd_and_ad_group_mapping/
    Vorletzter Beitrag erklärt (sehr ungenau), wie man die vorher genannte /etc/security/group.conf zur Geltung bring. Ich also an einer pam-Datei rumgefrickelt, jetzt kann ich mich an der Maschine gar nicht mehr anmelden. Muss ich nachher mal vom Stick starten, um die Datei wieder heilezumachen, seufz.

Es geht um Folgendes:

You’ll need the following line in your /etc/pam.d/ password-auth file or something… Just add the following line with your auth lines:

auth required pam_group.so use_first_pass



Then you can use /etc/security/group.conf like this:

*;*;%externalgroup;Al0000-2400;localgroup
Weiß jemand von Euch, welche Datei "or something" das genau ist? Ich habe offenbar die falsche genommen.

Wenn man das zum Laufen bekommt, hätte das (hoffentlich) den Effekt, dass man weiterhin die von @foer genannen Änderungen an der /etc/security/group.conf machen kann, die aktuell bei Ubuntu 18.04 bei Domänenanmeldung am grafischen Login leider keinen Effekt haben.

So, jetzt werde ich zur Erholung erst mal korrigieren.

Hi Andreas,

ich kenne den Sch. mit pam nur zu gut, weil ich gerade versuche einen Manjaroclient für die lmn7 zu bauen und genau da seit Tagen hänge…das ist grausam. Nun zu deinem Problem noch ein paar Gedanken/Ideen:

  1. Welchen Displaymanager benutzt du? Benutzt du sddm? Der ist bekannt dafür, mit pam Probleme zu machen. Installiere mal lightdm, den haben wir auch im Defaultcloop, weil er am besten mit pam zusammenarbeitet. Die passenden pam-Schnipsel für lightdm hänge ich unten an.

  2. zu deiner Frage:

Ja.

grep -rni /etc/pam.d/ -e 'pam_group.so'

/etc/pam.d/common-auth:29:auth optional pam_group.so
/etc/pam.d/login:46:auth       optional   pam_group.so

Hier kommen jetzt mal die o.g. Dateien. Versuche das doch nochmal erst mit den Einträgen von 2. und dann ggf. mit einem anderen Displaymanager! Bei mir läuft das mit der group.conf auch unter der v7 perfekt und das muss bei dir prinztipiell auch funktionieren…

pam-Dateien:

/etc/pam.d/common-auth:

# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.).  The default is to use the
# traditional Unix authentication mechanisms.
#
# 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)
auth	[success=2 default=ignore]	pam_unix.so nullok_secure
auth	[success=1 default=ignore]	pam_sss.so use_first_pass
# here's the fallback if no module succeeds
auth	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
auth	required			pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth	optional	pam_mount.so 
# end of pam-auth-update config

auth optional pam_group.so

/etc/pam.d/login

#
# The PAM configuration file for the Shadow `login' service
#

# Enforce a minimal delay in case of failure (in microseconds).
# (Replaces the `FAIL_DELAY' setting from login.defs)
# Note that other modules may require another minimal delay. (for example,
# to disable any delay, you should add the nodelay option to pam_unix)
auth       optional   pam_faildelay.so  delay=3000000

# Outputs an issue file prior to each login prompt (Replaces the
# ISSUE_FILE option from login.defs). Uncomment for use
# auth       required   pam_issue.so issue=/etc/issue

# Disallows root logins except on tty's listed in /etc/securetty
# (Replaces the `CONSOLE' setting from login.defs)
auth       [success=ok ignore=ignore user_unknown=ignore default=die]  pam_securetty.so

# Disallows other than root logins when /etc/nologin exists
# (Replaces the `NOLOGINS_FILE' option from login.defs)
auth       requisite  pam_nologin.so

# SELinux needs to be the first session rule. This ensures that any 
# lingering context has been cleared. Without out this it is possible 
# that a module could execute code in the wrong domain.  (When SELinux
# is disabled, this returns success.)
session    required   pam_selinux.so close

# This module parses environment configuration file(s)
# and also allows you to use an extended config
# file /etc/security/pam_env.conf.
# 
# parsing /etc/environment needs "readenv=1"
session       required   pam_env.so readenv=1
# locale variables are also kept into /etc/default/locale in etch
# reading this file *in addition to /etc/environment* does not hurt
session       required   pam_env.so readenv=1 envfile=/etc/default/locale

# Standard Un*x authentication.
@include common-auth

# This allows certain extra groups to be granted to a user
# based on things like time of day, tty, service, and user.
# Please edit /etc/security/group.conf to fit your needs
# (Replaces the `CONSOLE_GROUPS' option in login.defs)
auth       optional   pam_group.so

# Uncomment and edit /etc/security/time.conf if you need to set
# time restrainst on logins.
# (Replaces the `PORTTIME_CHECKS_ENAB' option from login.defs
# as well as /etc/porttime)
# account    requisite  pam_time.so

# Uncomment and edit /etc/security/access.conf if you need to
# set access limits.
# (Replaces /etc/login.access file)
# account  required       pam_access.so

# Sets up user limits according to /etc/security/limits.conf
# (Replaces the use of /etc/limits in old login)
session    required   pam_limits.so

# Prints the last login info upon succesful login
# (Replaces the `LASTLOG_ENAB' option from login.defs)
session    optional   pam_lastlog.so

# Prints the motd upon succesful login
# (Replaces the `MOTD_FILE' option in login.defs)
session    optional   pam_motd.so

# Prints the status of the user's mailbox upon succesful login
# (Replaces the `MAIL_CHECK_ENAB' option from login.defs). 
#
# This also defines the MAIL environment variable
# However, userdel also needs MAIL_DIR and MAIL_FILE variables
# in /etc/login.defs to make sure that removing a user 
# also removes the user's mail spool file.
# See comments in /etc/login.defs
session    optional   pam_mail.so standard

# Standard Un*x account and session
@include common-account
@include common-session
@include common-password
@include common-pammount

# SELinux needs to intervene at login time to ensure that the process
# starts in the proper default security context. Only sessions which are
# intended to run in the user's context should be run after this.  (When
# SELinux is disabled, this returns success.)
session required pam_selinux.so open

Hier noch die lightdm pam-Dateien falls nötig:

/etc/pam.d/lightdm

#%PAM-1.0
auth    requisite       pam_nologin.so
auth    required        pam_env.so readenv=1
auth    required        pam_env.so readenv=1 envfile=/etc/default/locale
#auth    sufficient      pam_succeed_if.so user ingroup nopasswdlogin
@include common-auth
auth    optional        pam_gnome_keyring.so
@include common-account
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
session required        pam_limits.so
@include common-session
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
session optional        pam_gnome_keyring.so auto_start
@include common-password

/etc/pam.d/lightdm-greeter

#%PAM-1.0
auth    required        pam_permit.so
auth    optional        pam_gnome_keyring.so
auth    optional        pam_kwallet.so
auth    optional        pam_kwallet5.so
@include common-account
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
session required        pam_limits.so
@include common-session
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
session optional        pam_gnome_keyring.so auto_start
session optional        pam_kwallet.so auto_start
session optional        pam_kwallet5.so auto_start
session required        pam_env.so readenv=1
session required        pam_env.so readenv=1 user_readenv=1 envfile=/etc/default/locale

Viel Erfolg und viele Grüße

Dominik

2 „Gefällt mir“

Hi Dominik,
wir verwenden schon lightdm, von daher sollte sich das gut umsetzen lassen, vielen Dank!
Ich melde mich, wenn ich es ausprobiert habe, und wünsche Dir sehr viel Erfolg bei dem Manjaro-Client.

off-topic:
Mein privater Hauptrechner läuft mit Arch (ursprünglich als Antergos installiert, jetzt nach dem Antergos-Ende auf Arch umgebogen), ein Zweitrechner mit Manjaro. Das sind Top-Distributionen. Ich ärgere mich bei meinem Kubuntu z.B. gerade darüber, dass der „malformed-url“-Bug beim Einstecken von USB Sticks, der in KDE schon seit 100 Jahren gefixt ist, noch nicht in 18.04 LTS (eher LT ohne S) Einzug gehalten hat. Ich hätte allerdings Sorge, dass man bei einer Rolling Release mit dem ganzen Domänenkram immer mal wieder was rumbasteln muss, aber Du scheinst Dich ja sehr gut damit auszukennen.

Ich hab nun Deine Dateien verwendet, damit gehts, super!

Wahnsinn, was man dabei alles falsch machen kann. Sowas wie sudo mv /etc/pam/login /etc/pam/login_alt ist eine GANZ schlechte Idee, weil nach dem (von mir gut gemeinten) sichern der alten Datei dann sudo nicht mehr geht! (musste ich auch mv statt cp nehmen, ganz blöd). Auch ein login als root geht nicht mehr, gar nichts geht mehr, außer vom Stick booten - mal wieder. Ein Hoch auf Linux vom Stick!

Also, besten Dank nochmal an @foer , ohne Dich hätte ich das niemals rausbekommen (dadurch, dass jede falsche Änderung an einer PAM Datei gleich zur völligen Dysfunktionalität des Systems füht, ist das per trial-and-error praktisch nicht rauszukriegen).
Gruß, Andreas

Hallo Andreas und Dominik und alle die Ubu18.04 unter der V7 am Start haben

wir haben auch die von Dominik angegebenen Dateien verwendet haben aber keinen Erfolg.
D.h. unsere Domänenuser können nicht in die Gruppen Lego oder Dialout aufgenommen werden.

Könnte man sich von offizieller Seite der Thematik annehmen? Ich denke das ist ein Feature, dass der Linuxclient braucht. Lego, Arduino usw sind einfach darauf angewiesen.

Wo jetzt unser Fehler stecken soll ist mir schleierhalft, denn wir habe eigentlich alles so gemacht wie bechrieben. Da das Thema aber so komplex ist ist eine Fehlersuche auch für uns kaum möglich…

Grüße Rainer

Hallo Rainer,

sende mal deine group.conf aus /etc/security.

Gruß Dominik

Folgendes ist mein Stand:

  1. Mit Dominiks Änderungen werden bei mir die Domänenuser in die gewünschten Gruppen aufgenommen. Allerdings hatten wir ohnehin schon lightdm verwendet, eventuel ist das bei @schajor nicht der Fall, dann müsstet ihr da auch noch Dominiks Änderungen anbringen!
  2. Arduino funktioniert nun für Domänennutzer, aber nur (!) wenn man „per Hand“ die aktuelle Arduino-Version von der Webseite installiert. die Arduino-Version, die bei 18.04 dabei ist, funktioniert nicht mit aktuellen Java-Versionen. Da wir die aktuelleren Java -Versionen aber brauchen (für Greenfoot etwa) war es für mich keine Option, Java zu Downlgraden (was vermutlich ginge)
  3. Lego Roberta funktioniert aber IMMER NOCH NICHT mit dem Domänenuser, obwohl ich in den richtigen Gruppen bin. Da Roberta ohnehin auf der Webseite speichert (bzw. in unserem Fall auf unserem lokalen Roberta Server) ignoriere ich das Problem jetzt. Ich versuche insgesamt nun schon seit über 2 Jahren, Roberta in unserem Schulnetz unter Linux zum Laufen zu bringen (wir hatten vorher ja auch schon Linux, nur einen anderen Schulserver) und bin gescheitert. Diese Roberta-Software, so schön sie auch zu benutzen ist, wenn sie läuft, funktioniert einfach wirklich schlecht unter Linux. Wir nutzen Roberta also mit einem lokalen User, die Schüler speichern ihre Programme auf der Webseite.

Immerhin hat sich der Aufwand mit den Gruppen für Arduino gelohnt, denn ohne Dialout-Gruppe läuft Arduino bei uns nicht, mit aber schon. Wie gesagt, Du brauchst die aktuellste Version!