The quest for su on Windows

“How to run cmd as different user?” I type into Google. When I search for full sentences instead of just keywords I must be very desperate. Violet links everywhere, I feel like I have tried everything and nothing works. What I want is something like “su”, temporarily changing the current user sounds like a very important thing to be able to do when one administrates Windows. So why is it not that simple?
There is a command called “RunAs”, sounds good, right? Just give the user and command you want to use and you are set! Just make sure you have the right permissions. But problems start with the username since Windows is localized. Sometimes English names work, sometimes you need to use “NT-AUTORITÄT\Netzwekdienst” instead of “NT AUTHORITY\Network Service”. RunAs is one of the latter. Except all of this does not matter since you need a password and system accounts tend to not have one. Bummer.

Notice the differences in the output between the English and German username


Without knowledge of Windows inner workings, I blame the lack of quality free material on the topic, I’m left to googling around until I find a 10 year old blog post or forum entry which solves the exact problem I’m having. And I did find something, it’s not even that old. PsExec is a tool which does exactly what I want! So I install the package, edit my path, run the program… and it just works! With English usernames even. (After I used the -accepteula flag, because for some reason it would not work without when running the first time).

It just works!


Working with Windows often feels to me like piloting a military submarine, not because it’s so advanced, but because I often have no idea what I am doing, the manual is in Russian and clicking the wrong button may or may not make a large strip of land uninhabitable for decades. Trial and error seems to be the way to go for most problems and that’s frustrating. So I hope if somebody else finds themselves in the unknown waters of the Windows user system, this blog post can help.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 3: Plugins

This entry is part 3 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

Heute gehen wir der Frage nach wann und wie Plugins installiert werden sollten, was besonders wichtig bei Systemen mit icinga Benutzern zum Gegensatz nagios zu beachten ist. Auf z.B. RedHat-Systemen besteht das Problem, dass der Prozess Icinga 2 unter dem Benutzer icinga läuft, aber unteranderem das Plugin check_icmp oder auch check_dhcp nur vom Benutzer root oder einem Mitglied der Gruppe nagios mittels suid-Bit ausgeführt werden können.

# ls -l /usr/lib64/nagios/plugins/check_icmp
-rwsr-x---. 1 root nagios ... /usr/lib64/nagios/plugins/check_icmp

Das Ändern der Gruppenzugehörigkeit mit Puppet ist wenig hilfreich, da leider bei einem Update des Paketes nagios-plugins die alten Berechtigungen wieder hergestellt werden. Man könnte nun natürlich den Benutzer icinga und das Paket nagios-plugins explizit vor der Klasse icinga2 managen, verliert dann jedoch die Paketkontrolle über die uid und muss das Home-Directory, Shell und weitere Eigenschaften per Hand in Puppet entscheiden. Klarer ist die Methode genau diese Sachen dem Paket zu überlassen und erst danach icinga in die Gruppe nagios aufzunehmen.

yumrepo { 'icinga-stable-release':
  ...
}
->
package { [ 'icinga2', 'nagios-plugins' ]:
  ensure => installed,
}
->
user { 'icinga':
  groups => [ 'nagios' ],
}
->
class { '::icinga2':
  manage_package => false,
}

Um dieses Vorhaben umzusetzen ist es erforderlich die benötigten Repositories zuerst einzubinden, hier mit yumrepo angedeutet, dann die Pakete zu installieren, den Benutzer anzupassen und erst dann die Klasse icinga2 zu deklarieren.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Icinga Web 2 – Das darf nicht jeder

Icinga LogoIch möchte heute auf die verschiedenen Möglichkeiten eingehen, in Icinga Web 2 zu steuern wer was sieht und machen darf. Gerade in Unternehmen mit vielen Mitarbeitern oder einem großen Kundenkreis ist dies von essentieller Bedeutung für die Antwort auf die Frage, ob man Icinga Web 2 produktiv einsetzen kann, oder nicht. Da wir uns nun langsam auf den ersten Release Candidate hinzu bewegen, soll dieser Eintrag auch dazu dienen, zu präsentieren was in dieser Hinsicht noch zu erwarten ist.

Das Gruppen-/Rollen-Konzept

Erst einmal etwas zur Grundlage. Wer bereits weiß was der Titel verheißt, darf gerne direkt zum nächsten Abschnitt springen. In Icinga Web 2 gibt es Benutzer (Nicht zu verwechseln mit Icinga’s Kontakten. Von Icinga Web 2’s Benutzern weiß nur Icinga Web 2 etwas!) die sich auf verschiedenen Wegen anmelden können. (Basic-Auth, Datenbank, LDAP, …) Wurde konfiguriert wie Gruppen bestimmten Benutzern zugeordnet werden (Datenbank, LDAP, …), wird Icinga Web 2 versuchen nach erfolgreicher Anmeldung eines Benutzers seine Gruppen-Zugehörigkeiten zu registrieren. Nun existieren alle notwendigen Informationen, die verfügbaren Rollen einem Benutzer zuzuordnen. Eine Rolle definiert die Berechtigungen und Einschränkungen die für bestimmte Bereiche in Icinga Web 2 anzuwenden sind.

Berechtigungen

Eine Berechtigung definiert thematisch wer was sieht und machen darf, nach dem Motto “alles oder nichts”. In Bezug auf Icinga Web 2 selbst (also die Applikation an sich), trifft das auf die Konfiguration zu. Ob ein Benutzer alles, nur die Rollen oder die Benutzer und auch die Gruppen konfigurieren darf, wird mittels bestimmter Berechtigungen kontrolliert. Auch das Monitoring Modul (das eigentliche Herz, welches mit Icinga kommuniziert) bietet die Möglichkeit Berechtigungen zu definieren. In diesem Fall allerdings trifft dies auf die Kommandos zu, ob ein Benutzer alles, nur Kommentare hinzufügen oder Acknowledgements senden und auch Downtimes definieren darf. (Diese Berechtigungen stehen nicht mit bestimmten Hosts oder Services in Verbindung, sondern gelten für alle gleichermaßen.)

Einschränkungen

Eine Einschränkung wird zusätzlich zu einer möglicherweise notwendigen Berechtigung angewendet und, wie der Name schon sagt, schränkt den eigentlichen Zugriff noch weiter ein.
Dies geschieht aktuell im Monitoring Modul für Hosts und Services und schränkt die Anzeige der eigentlichen Objekte und, mit dem Release Candidate, auch ihrer entsprechend verknüpften Daten (Events, Kommentare, …) ein. (Sobald der Release Candidate verfügbar ist, wird dies auf Host- und Service-Gruppen sowie alle möglichen Aliase und Customvariablen ausgedehnt. Ob auch eine automatische Verknüpfung eines Benutzers mit einem Kontakt erfolgen kann, ist noch nicht endgültig entschieden.)
In Bezug auf Customvariablen gibt es im Monitoring Modul eine Besonderheit: Es ist möglich den Zugriff auf bestimmte Customvariablen vollständig zu sperren, unabhängig einer Rolle. Dies ist meist sinnvoll, wenn dort sensitive Informationen wie Passwörter o.ä. existieren.

Die URL Filter-Syntax

Da die Definition einer Einschränkung für Hosts und Services aktuell mittels eines URL Filters (wie sie überall in Icinga Web 2 verwendet werden) geschieht und es in der entsprechenden Konfigurations-Ansicht keinerlei Hilfestellung hierfür gibt, zeige ich zum Abschluss wie so ein Filter aussehen kann. Findige Nutzer werden evtl. bereits auf die Idee gekommen sein, den Editor in den entsprechenden Listen-Ansichten zu verwenden. Denn dort ist es aktuell möglich, sich die gewünschten Filter einfach “zusammen zu klicken”. Hat man all seine gewünschten Filter angewendet, erscheint deren Repräsentation in der Address-Zeile des Browsers und kann von dort direkt übernommen werden:
/icingaweb2/monitoring/list/hosts?(hostgroup_name=customer1|hostgroup_name=customer2)&host_name=office-*
Hier kann man bereits den grundlegenden Aufbau erkennen. Es sind Verknüpfungen (OR = |, AND = &, NOT = !) und Vergleiche (EQUAL =, NOT EQUAL = !=, GREATER = >, LESS = <, GREATER OR EQUAL = >=, LESS OR EQUAL = <=) möglich. Möchte man mehrere Bedingungen zusammenfassen, setzt man sie in runde Klammern. Sollen nun nur noch Hosts der Hostgruppe "customer2" zutreffen, welche eine bestimmte Customvariable besitzen, (Eine Funktion die aktuell leider nur mit Icinga 1.x funktioniert, mit dem Release Candidate allerdings auch mit Icinga 2.x.) muss der Filter folgendermaßen angepasst werden: (hostgroup_name=customer1|(hostgroup_name=customer2&_host_support_level>=2))&host_name=office-*
Handelt es sich um einen Service, sieht die Notation für Customvariablen folgendermaßen aus: _service_variable_name

In diesem Sinne, wünsche ich euch ein fröhliches berechtigen und einschränken. Bis demnächst, wenn’s mal wieder etwas von Icinga Web 2’s pure awesomeness zu berichten gibt. 😀

Johannes Meyer
Johannes Meyer
Developer

Johannes ist seit 2011 bei uns und hilft bei der Entwicklung zukünftiger Knüller (Icinga2, Icinga Web 2, ...) aus dem Hause NETWAYS.