Æ-DIR -- Authorized Entitites Directory
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Untertitel |
| |
| Serientitel | ||
| Anzahl der Teile | 40 | |
| Autor | ||
| Mitwirkende | ||
| Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/54434 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
openSUSE Conference 20193 / 40
7
11
12
13
15
16
17
18
19
20
23
25
26
27
34
38
40
00:00
IdentitätsverwaltungDatenverwaltungVerzeichnisdienstCOMComputersicherheitGrenzschichtablösungDatenverwaltungSoftwareVerzeichnisdienstComputersicherheitProjektive EbeneClientUnicodeBildschirmmaskeJSON
01:09
GrenzschichtablösungComputersicherheitCOMGruppenoperationComputersicherheitSystemprogrammierungAusnahmebehandlungKontextbezogenes SystemDatenverwaltungPhysikalisches SystemVerzeichnisdienstGarbentheorieGrundraumComputeranimationVorlesung/Konferenz
02:10
ComputersicherheitElektronischer DatenaustauschCOMGrenzschichtablösungPhysikalisches SystemGruppenoperationSocial Engineering <Sicherheit>TopologieQuellcodeSystemverwaltungZahlenbereichSchlussregelVererbungshierarchieGamecontrollerProxy ServerTaskHilfesystemFokalpunktSoftwarewartungÄußere Algebra eines ModulsSystemprogrammierungProjektive EbeneWeg <Topologie>Rechter WinkelVerzeichnisdienstAbfrageIntegriertes InformationssystemMobiles InternetFormation <Mathematik>PasswortSoftwareData-Warehouse-KonzeptJSON
04:43
KontrollstrukturCOMComputersicherheitRechnernetzFront-End <Software>GrenzschichtablösungProgrammierumgebungGrenzschichtablösungComputersicherheitSystemprogrammierungProjektive EbeneImplementierungSoftwareComputeranimation
05:21
RechnernetzCOMComputersicherheitFront-End <Software>GrenzschichtablösungProgrammierumgebungKontrollstrukturSoftwarewartungAutorisierungEin-AusgabeNebenbedingungSchlussregelProdukt <Mathematik>SystemprogrammierungSoftwaretestSoftwareentwicklerMAPGrenzschichtablösungDimensionsanalyseDatenstrukturSoftwareAggregatzustandNichtlinearer OperatorGamecontrollerVerweildauerElektronisches ForumPhysikalisches SystemVorlesung/KonferenzComputeranimation
06:40
AutorisierungSoftwarewartungNebenbedingungEin-AusgabeSchlussregelCOMAuthentifikationProxy ServerDatenstrukturDatenstrukturPhysikalisches SystemAutorisierungProgrammierparadigmaComputeranimation
07:36
COMAutorisierungAuthentifikationProxy ServerDatenstrukturOvalDatenstrukturGruppenoperationObjekt <Kategorie>PasswortEindringerkennungComputerarchitekturProgrammierparadigmaPhysikalisches SystemMehrplatzsystemIdentitätsverwaltungDatenbankProxy ServerSystemprogrammierungSchlussregelRechter WinkelLeistung <Physik>Grundsätze ordnungsmäßiger DatenverarbeitungEinfach zusammenhängender RaumPunktHierarchische StrukturMini-DiscVerzeichnisdienstSystemverwaltungDatenverwaltungSchlüsselverwaltungQuaderStabMereologie
10:10
App <Programm>Architektur <Informatik>CDMACOMServerDivisionTorusTopologieVerzeichnisdienstGruppenkeimZugriffskontrolleRelation <Informatik>ZeitzoneDienst <Informatik>GruppenoperationDienst <Informatik>GruppenoperationGeradeOffene MengeComputersicherheitInstantiierungMAPBootenTeilbarkeitService providerNichtlinearer OperatorFlächeninhaltLoginObjekt <Kategorie>SystemprogrammierungInhalt <Mathematik>QuellcodePhysikalisches SystemElement <Gruppentheorie>InformationsspeicherungFormation <Mathematik>Zeiger <Informatik>Notepad-ComputerTabelleMereologieMixed RealityAttributierte GrammatikRechter WinkelKartesische KoordinatenVisualisierungRegelkreisComputerarchitekturGamecontrollerServerPasswortAuthentifikationSoftwarewartungSichtenkonzeptSystemverwaltungVererbungshierarchieArithmetisches MittelE-MailWeb SiteRichtungBefehl <Informatik>BenutzerbeteiligungNatürliche ZahlProzess <Informatik>SoftwareGreen-FunktionVerkehrsinformationSynchronisierungProxy ServerZeitzoneRuhmasseDämon <Informatik>SchlussregelLeistung <Physik>Mailing-ListeToken-RingROM <Informatik>VerschlingungCASE <Informatik>Hierarchische StrukturPrinzip der gleichmäßigen BeschränktheitRootkitDiagrammVollständigkeitWeb-ApplikationAbstraktionsebeneVersionsverwaltungNichtunterscheidbarkeitKlasse <Mathematik>Kette <Mathematik>Bit
18:47
PasswortMathematikZeitzoneSystemverwaltungGruppenoperationDienst <Informatik>COMStandardabweichungClientKonfigurationsraumAbstraktionsebeneVererbungshierarchieHybridrechnerGruppenkeimAutorisierungAdressraumDynamic Host Configuration ProtocolPhysikalisches SystemEindeutigkeitNebenbedingungZeitzoneClientOffene MengeDatenverwaltungPasswortMetadatenServerNormalvektorGruppenoperationMailing-ListeSoftwareE-MailMultiplikationsoperatorKlasse <Mathematik>Objekt <Kategorie>LoginSystemprogrammierungAbstraktionsebeneAttributierte GrammatikHybridrechnerElement <Gruppentheorie>GamecontrollerComputersicherheitAutorisierungIdentifizierbarkeitEindeutigkeitSystemverwaltungSoftwarewartungDifferenteLesen <Datenverarbeitung>ROM <Informatik>Kontextbezogenes SystemRegulator <Mathematik>DatenmissbrauchStrategisches SpielCOMMoment <Mathematik>StandardabweichungFormation <Mathematik>AusnahmebehandlungIntegriertes InformationssystemEinsDivergente ReiheStabMeterInformationsspeicherungMixed RealityGleitendes MittelNichtlinearer OperatorMetropolitan area networkDeskriptive StatistikTopologieComputeranimation
24:38
Physikalisches SystemEindeutigkeitNebenbedingungSystemverwaltungZeitzoneAutorisierungAdressraumPublic-Key-InfrastrukturRechenwerkKegelschnittGruppenoperationGamecontrollerDomain <Netzwerk>SoftwareAdressraumZahlenbereichPhysikalisches SystemIntegriertes InformationssystemDigitales ZertifikatNetzadresseDomain-NameObjekt <Kategorie>DeterminanteEindeutigkeitDirekte numerische SimulationMultiplikationsoperatorProgramm/Quellcode
25:59
Kanal <Bildverarbeitung>Dienst <Informatik>KonfigurationsraumVerzeichnisdienstWeb SiteCOMFächer <Mathematik>DefaultZeitzoneZeitbereichPeer-to-Peer-NetzPunktKonfiguration <Informatik>Normierter RaumWeb-ApplikationProzess <Informatik>AuthentifikationMechanismus-Design-TheorieComputersicherheitBitPhysikalisches SystemProfil <Aerodynamik>KonfigurationsraumApp <Programm>Zusammenhängender GraphNamensraumWeb SiteSchlüsselverwaltungComputerarchitekturAssoziativgesetzKartesische KoordinatenNichtkommutative Jordan-AlgebraDämon <Informatik>Bildgebendes VerfahrenSystemaufrufMinkowski-MetrikKonfiguration <Informatik>MultiplikationsoperatorComputeranimation
27:37
COMBefehlsprozessorPasswortParallele SchnittstelleServerHome location registerKraftProxy ServerAutorisierungWeb SiteBitDienst <Informatik>GamecontrollerRegelkreisComputeranimation
28:17
ZeitzoneGruppenkeimDienst <Informatik>ZugriffskontrolleGruppenoperationProxy ServerDefaultServerKonfigurationsraumVerzeichnisdienstWeb SiteCOMZeitbereichPeer-to-Peer-NetzPunktKonfiguration <Informatik>BefehlsprozessorPasswortParallele SchnittstelleHome location registerServerGamecontrollerPasswortDienst <Informatik>ClientDreiecksfreier GraphGruppenoperationBefehlsprozessorEinfach zusammenhängender RaumKonfigurationsraumSpeicherabzugVerzeichnisdienstKonfigurationsverwaltungSingularität <Mathematik>AbfrageProgrammierumgebungTwitter <Softwareplattform>RichtungComputeranimationFlussdiagramm
30:17
BefehlsprozessorPasswortParallele SchnittstelleServerClientLoginCodeKonfigurationsraumLastteilungPhysikalisches SystemKonfigurationsraumGesetz <Physik>LastComputersicherheitClientDienst <Informatik>PunktLastteilungRuhmasseComputeranimation
31:12
Physikalisches SystemNabel <Mathematik>COMSchlussregelPasswortBimodulServerZusammenhängender GraphAdditionInstantiierungPhysikalisches SystemGruppenoperationGrenzschichtablösungAutorisierungNormalvektorRootkitDebuggingSystemprogrammierungHome location registerCASE <Informatik>MAPFront-End <Software>Dienst <Informatik>Prozess <Informatik>VerzeichnisdienstEndliche ModelltheorieNichtlinearer OperatorFlussdiagramm
33:11
GruppenoperationUmwandlungsenthalpieCOMSchlüsselverwaltungKontrollstrukturObjektverfolgungPasswortLoginFluidSichtenkonzeptStellenringApp <Programm>Wort <Informatik>Token-RingDienst <Informatik>Gebundener ZustandAusgleichsrechnungVirtuelle RealitätHilfesystemHill-DifferentialgleichungFormation <Mathematik>LoginGruppenoperationClientSichtenkonzeptMAPNormalvektorEindeutigkeitFlächeninhaltRechter WinkelArithmetisches MittelVirtualisierungObjekt <Kategorie>Message-PassingExistenzsatzIntegriertes InformationssystemGrundraumComputeranimation
35:07
GruppenoperationUmwandlungsenthalpieCOMSchlüsselverwaltungKontrollstrukturObjektverfolgungPasswortLoginComputersicherheitClientServerGamecontrollerPhysikalisches SystemComputerforensikNetzadresseOffene MengeWeg <Topologie>Gewöhnliche DifferentialgleichungSchreib-Lese-KopfDienst <Informatik>Computeranimation
35:48
SichtenkonzeptGruppenoperationUmwandlungsenthalpieSchlüsselverwaltungKontrollstrukturObjektverfolgungLoginPasswortCOMMathematikComputersicherheitSystemverwaltungDatenverwaltungPasswortClientLoginKonfigurationsraumStellenringMixed RealityEinfach zusammenhängender RaumVirtuelle MaschineComputersicherheitVerzeichnisdienstAutomatische HandlungsplanungProzess <Informatik>GenerizitätPersönliche IdentifikationsnummerMultiplikationsoperatorBootenVollständiger VerbandComputeranimation
38:17
ComputersicherheitSystemverwaltungDatenverwaltungMathematikVerschlingungDemo <Programm>COMProjektive EbeneDatenverwaltungHilfesystemComputersicherheitOpen SourceAuthentifikationInformationDemo <Programm>App <Programm>p-BlockVerzweigendes ProgrammNatürliche ZahlTeilbarkeit
39:24
SystemverwaltungComputersicherheitZugriffskontrolleGruppenoperationLoginRechenschieberDifferenteStellenringAggregatzustandDienst <Informatik>AutorisierungBenutzerbeteiligungMessage-PassingMathematikNatürliche ZahlServerAttributierte GrammatikDatei-ServerSupergruppePublic-Key-KryptosystemElektronische PublikationMAPVorlesung/Konferenz
41:03
Inklusion <Mathematik>SichtenkonzeptClientGeradeGruppenkeimWeb SiteResultanteGruppenoperationZusammenhängender GraphLoginDienst <Informatik>URLKonfigurationsraumServerAuthentifikationMereologieIntegralNichtunterscheidbarkeitVerzeichnisdienstRechter WinkelPasswortCase-ModdingUmwandlungsenthalpieBenutzerbeteiligungComputeranimation
42:57
AutorisierungPasswortOpen SourceKonfiguration <Informatik>LoginInstantiierungFreewareProjektive EbeneDienst <Informatik>SystemprogrammierungRippen <Informatik>Vorlesung/KonferenzBesprechung/Interview
44:23
Videokonferenz
Transkript: Englisch(automatisch erzeugt)
00:06
Hi, I'm going to present Authorized Entities Directory. In the short form, it's called AIDE with this strange Unicode character there. Yeah, depending on the language,
00:22
it's Scandinavian or very old German or something. It's for challenging the Unicode capabilities in software a little bit. It already failed on the free note in some chat clients.
00:40
Authorized Entities Directory is mainly a user management based on OpenLLap. And yeah. So it's me. I'm doing stuff. The reason why Authorized Entities Directory exists is that I was in a customer project.
01:03
And the security guys said, OK, your elder-based management, your elder-based user management is quite good. But you should take care of that users and groups should only be visible on systems where they have to be visible.
01:23
And we all know these principles. Basically, those general security requirements you can read in every security concept. So everybody is writing it down in their security policy. Oh, we are following need-to-know principle.
01:40
We are following least privileged principle. But I scratched my head, and I thought to myself, well, all the directory solutions, all the user management solutions are not really following these principles. So for example, if you attach all your Linux systems to an Active Directory, be aware
02:01
that every user and every system sees almost everything. There are only very few exceptions of data in the Active Directory tree which are hidden behind access control rules. But basically, in every company using Active Directory,
02:24
every user can query who are the members of the super duper admin group and what's their mobile number. So I'm seeing a lot of Active Directory deployments where all contact data is also put in there.
02:42
So this is for social engineering attacks or preparing attacks. That's a very useful source. So I've looked around for alternatives, and I don't want to mention other projects.
03:01
But all the alternatives and the systems I set up before myself, they all focus on providing data. They're not focusing on hiding data. So I had to build a system like this myself.
03:24
And another aspect why this exists is that I wanted to have a system where you can consequently delegate the task of data maintenance to other people. So in practice, you have this help desk proxy roles.
03:47
Your users write a ticket. I need access to this resource. And so a help desk user has the right to put you into a certain permissions group and things like that. But this is always a workflow.
04:03
It's a workflow. So but I want to delegate this task. So whoever is authorized to decide whether somebody gets access to a resource, he or she should just do it.
04:22
And of course, what you need in such a system is meaningful audit trails. You have to record who did what and for doing compliance checks afterwards. Well, there's a buzzword called DevOps
04:43
since quite some years now. And there's another buzzword saying SecDevOps. And well, I would say you cannot do really good DevOps without the security in there. And therefore, it means that if you
05:05
have several teams maintaining systems for several projects, you have to implement. You have to define security policies and really enforce those security
05:21
policies in a fine-grained way. And the separation of the systems could be inspired by, for example, a network separation you already have or can be inspired by organizational structure or can be inspired also
05:41
by the staging of your systems. For example, you have development systems, test systems, or production systems. And this is one dimension how to structure your access control policy. And a system to be, so the system I wanted to design
06:04
has to be flexible enough to accommodate all those dimensions. So it has to be free enough for you to decide yourself which structure your access control has.
06:23
Yeah, as said before, the normal thing is you trigger a workflow to get access to a resource. But that's not really agile. Agile is another buzzword. But I'm trying here to really eliminate workflows.
06:41
Just say somebody is authorized to decide. So he's authorized to do it technically him or herself. So for this delegation, you obviously also need fine-grained authorization structures.
07:03
So just to summarize, a few of the paradigms I tried to following with this system is explicit is better than implicit. So everything has to be really made explicitly available. It's not just available because somebody
07:20
has an account or something. So obviously, this requires that everything you want to authorize, the entities, all the entities have to securely authenticate to get access to data or to some function.
07:44
A paradigm which is really hard to follow is to avoid all mighty proxy rules. In practice, for example, if you have an identity management system, the identity management system
08:00
is mainly a huge database with a lot of connectors. And those connectors, they pump data into the target systems. And they have very strong, they have very powerful access rights. Mainly, they are God in the target systems.
08:23
And once your connector gets hacked, the attacker has every access right in the target. One also very important paradigm
08:41
is to avoid, to structure access rights based on hierarchy. So in Active Directory, for example, delegation is somewhat flexible. But the structure, how you structure your objects, the resources, it's hierarchical,
09:00
strictly hierarchical along the so-called OU structure. And I didn't want that. So another important point is that this system distinguishes strictly between personal objects and their connected user objects.
09:20
So a person is not a user account. It doesn't even have a password. It's just a personal object. And you can have multiple user accounts tied to this personal object. And one very strict paradigm is that IDs assigned,
09:43
for example, to users and to groups are never reused. So basically, there's nothing really removed inside there. Better to say, user accounts and groups are never reused. So to keep their IDs persistent.
10:09
So this is a picture of the system architecture. And basically, here on the right, top corner,
10:21
there's a system where it's running in a writable replica, a writable instance of the OpenLDAP server daemon called Slabty. And I use the pointer. And mainly, the system is maintained,
10:43
the data is maintained either directly over LDAP or through in the web app. So the official API for maintaining data, for doing mass data maintenance is really direct LDAP access.
11:02
The reason for this is that all the access control is implemented by OpenLDAP access control lists. So there's no proxy or something enforcing security policy, it's just the OpenLDAP server itself. There are some web apps, one very powerful web app,
11:21
and then another web app, for example, for password self-service. And then another simple web app for enrolling Yubikey tokens. And a bunch of cron chops maintaining data. For example, a typical scenario would
11:41
say you have an HR system where your personal data is, and one of the maintenance jobs syncs person data into the system as person objects. And here are the so-called consumer replicas.
12:01
Mainly, it's just a replicated instance of the OpenLDAP server. But below this red line, all the replicas are read-only, so you cannot write there. You cannot alter data there. That's for security reasons.
12:20
So you have a two-tier architecture with writable provider replicas and read-only consumer replicas. Also, some of the data is not available on the consumers, because it does not have to be there. For example, shared secrets for the two-factor authentication.
12:42
And typically, the admin would go to a Unix server, for example, doing login there. And you have the usual PAM-NSS access over LDAP clearing the data.
13:00
OK, I said the access control is not based on hierarchical data, and that's indeed the case. But of course, that's an LDAP server, so the data is hierarchically organized. On the below the top level, you have the so-called zones.
13:21
Zones are just areas of delegated administration. Can be anything. Can be inspired by your stages, or can be inspired by your teams, or a mixture of everything. It's just the level below the root node is just zones. And there are special zones. For example, there's a pub zone.
13:42
A pub zone contains data which can be read by any authenticated user. And there's also a special zone for administering the system itself. It's self-contained. The system is maintained with itself.
14:03
And within a zone, like here, the example zone, you have users and user groups, and you have service groups. You have pseudo rules. And you might have special user groups, which make up the roles acting within the zone
14:24
for delegating zone maintenance. Below the service groups, you can have host objects or server services objects. And below the host objects, you can even store network device data if you want that.
14:42
That's optional. So this is the shocking picture of the complete entity relationship diagram. As you can see, you can see nothing. And so I have a more friendly version of it. It's an excerpt of the former one.
15:00
And this is the most important picture for understanding how the access control within the system works. And basically, a very central element is the so-called service group. A service group is, you can say, a clustered service,
15:21
for example. Or you could also say, the abstraction level is a group of hosts where you want to apply the same security policy. And basically, defining the security policy
15:40
is setting links to user groups. And this is this arrow. Oh, yeah. And the picture you have to read like this within the name, within the square,
16:05
it's the name of the object class of the LDAP entry. And basically, you have pointers, which are just the distinguished names of other referenced entries.
16:20
And you can see here. You can have several attributes containing references to other entries. And service groups are referencing user groups. And those user groups can also have members, which can be personal user accounts, which are connected to a personal object,
16:44
or tool accounts, service accounts, whatever you like to call it. So in the beginning, I said the most important part is really the need-to-know principle,
17:00
enforcing a need-to-know principle. And this is done by each host must authenticate itself to the system and is then member of a service group. And this service group, you have to set this attribute
17:22
A visible groups to make a group and its members visible on these hosts. So if this chain of references is not complete, a user object is not seen. And this is quite nice.
17:40
There's also another. You can also distinguish a little bit excess rights in some sense, because you can also say you don't. Additionally, you define which user groups have login rights
18:01
on the target systems. This is by setting the reference attribute AE login groups. So you can also distinguish whether groups and their members are only visible or whether they also have the login right.
18:23
There are more attributes. I call this somewhat permission attributes. I come to that later. And you also have to make pseudo rules applicable on the systems explicitly available, just like the groups with the attribute AE visible pseudo us.
18:47
If you have any question in between, don't hesitate to ask. OK, so there are some basic roles. Mainly, there are two global admin and auditor roles.
19:04
The AE admins, mainly, they can do everything. But in their daily work, they only delegate zones. They create zone entries. They might fix broken entries. But they do not maintain normal data within the zones.
19:25
They're really advised to keep out of the daily data maintenance business. It's the highest role. They can do everything. But they should not help the normal zone admins to do the normal data work, because they do not
19:42
know about all the data in different zones. They don't know the context of some objects stored there. They just maintain itself. As such, also, AE auditors, they can read everything.
20:01
If you have security audits going on or something, you can give a temporary account to a security auditor coming to your company. But he cannot write anything except his own password. And the daily work, really maintaining users,
20:22
putting them in groups, and stuff like this is done by the zone admins. And they have this role delegated by the zone definition. And obviously, there's also a need for giving people read-only access to zones, for example,
20:44
so that, for example, zone admins of two different zones can work together by giving each other read access to their own zone. And users may read their own entries, for example,
21:02
to comply to privacy regulations. They can ask which data is stored about me. And obviously, they can change their password. So I'm looking on open LDAP mailing list since 20 years.
21:24
And one of the main hurdles for people setting up user management based on open LDAP is schema. People really hate it sometimes. And I can somewhat understand it because there are various different schemas.
21:42
You have to find out whether to use one. And it also depends on the client applications, which schema they need, and stuff like this. So it can be confusing for people starting to get into it. And therefore, I try to define a schema which accommodates
22:05
every client out there I know of. So it's based on standard schema, like a network person for personal data or the RFC 2307,
22:22
the POSIX account, POSIX group schema, the very old one. But it also has custom schema in there. So the goal with the schema design was to behave like any normal LDAP server out there
22:42
to the client. But still, you need to store some additional metadata. And this is not data usually used by the external clients. So each object has an abstract object class called AEObject.
23:08
And there you have some metadata, like a status attribute, or a description, or something like a time span the entry can be used.
23:23
And one of the real issues with if you want to do Unix log-in systems is choosing the right group schema. Because there are basically two variants of the POSIX group schema, which
23:41
is an old one, which has the user name stored in the member UID attribute, and another more recent schema, where you store the membership into the member attribute.
24:00
And this is not compatible. So people run usually into problems, which schema to choose, and sometimes they are not free. So I solved this problem by having a hybrid group schema, which just serves both from the same group entry.
24:25
OK, so what's very important if you're doing authorization is uniqueness of identifiers. I sometimes wonder why I have to repeat this so often. But uniqueness, if you don't enforce uniqueness, you are not able to implement a secure access control policy.
24:44
So of course, user names have to be unique. UID numbers, the POSIX UID and the POSIX GID have to be unique. But also group names. Or for example, also very interesting, the host names,
25:00
for example. Or even storing something like a unique fully-qualified domain name for, for example, network addresses. And you can do all this here. So basically, you can add host objects and their network data.
25:21
So you can even have uniqueness enforced on the DNS names of the IP addresses and also enforce uniqueness, for example, on MAC addresses so that you can find out who is responsible for that name.
25:40
And you can do a lot of interesting stuff with this, for example, network access control or determine in the PKI who is allowed to request a server certificate for a certain fully-qualified domain name. OK, I have to, oh, time is running.
26:02
So I will hurry up a little bit because I'm famous to have too many slides. Installation of ID is completely Ansible-based. You mainly define the inventory, run the Ansible play, and you're done. Then all the replicas and web applications are up and running.
26:24
In the meantime, it proved to be very stable, very robust. It really corrects former configuration faults. And it works pretty well.
26:40
By default, I'm trying to really apply some security principles and use as many security mechanisms available. For example, OK, it's self-contained. I already said this. But I'm also using, by default, some systemd options,
27:01
which harden the system by calling setNSCalls for the, by doing setNSCalls and restrict the processes to namespaces. And for each of the components you saw in the system architecture, there's an app armor profile
27:21
defined for that. And there's also built-in Yubikey-based or HOTP-based two-factor authentication you can mainly use with Yubikeys. I skipped this. This is a little bit.
27:41
You can read about this a little bit on the website because that's an authorizing SSH proxy, which is basically a pretty good thing. So last summer, I've developed, I've even developed an NSSPAM service for the whole stuff
28:03
because formally, we used SSD for this. But if you have, for example, 15,000 systems, the access control is pretty demanding. So going back to this, really determining
28:22
which users are visible on the system, the OpenLDAP server has to work its way through all the references with so-called set-based access control. And the set-based ACLs are pretty CPU-consuming. So if you have many clients, like 15,000 or so,
28:44
you're burning a lot of CPU cycles. You're burning a lot of electrical power. So for doing something for the environment, therefore, OK. The reason for this is that the clients are deliberately configured dump.
29:02
You don't configure something like, oh, I just want to have users of this group on the client because this would be very inflexible. So even if you have configuration management, you would have to change the access control in the directory and then apply configuration to the clients.
29:23
I don't want that. So the clients are really dump. They just query the LDAP server saying, oh, give me everything I'm allowed to see. So mainly, they are doing this. So this burns a lot of CPU cycles. And another thing is every host and every service
29:41
has to authenticate itself, so mainly by a host password. And I needed a better way to automatically enroll many hosts. And the customer using this, he also
30:00
used pseudo LDAP, which does an LDAP connection for each pseudo. And that's also lots of TLS connection. And also, the connection behavior of clients, like SSD, you cannot really influence that.
30:24
I wanted to implement some kind of a client-side load balancing from mass of NSF PEM clients. And yeah, and having an own service,
30:40
it's also possible to implement some features I was tired to ask for. OK, better performance, better behavior of lots of clients, automated enrollment, and especially have less configuration, less code, which is security relevant, and less dependencies.
31:02
So a host, for example, has no dependency on system D and D bus, for example. So how does it look like? You see here a normal SSH server. And the server mainly uses NSS and PEM, NSS,
31:24
for querying which users are available on the system, which groups, and which IDs they have. And check, for example, a password or an authorization through PEM. And basically, these two modules I didn't implement.
31:41
What I have implemented is just the AE host day here. These two modules are the PEM and NSS front end modules of NSS PEM LWD, also known as NSLCD. OK, so basically, I replaced NSLCD by this component.
32:04
And this component does several things, of course, providing password group maps, but it also provides an opposite to SSD, for example. It also provides the host map, which can be a nice fallback in some cases. And it also queries which sudoers rules
32:24
are available for this system and syncs it to the etc sudoers directory. Basically, there are two instances running.
32:40
And this was also something important to me, because in normal setups, SSD is running as root. I don't want that. I don't want to have a networked component just running as root. So I have a non-privileged user running the AE host day for getting the data.
33:03
And I have a privileged additional component putting, for example, sudoers rules in place. OK, so there are some specific features also.
33:21
The permissions group I showed before, for example, log in or log few groups. So they are put into virtual groups in the etc group map. I show an example.
33:46
So we are here on a normal client. And this is a user. We can do the usual stuff. For example, you see here, OK, they're coming AED user accounts.
34:03
And those accounts have, of course, a unique POSIX ID. But they also have a unique POSIX GID. And if I call ID on one of the users, you can see that there's a virtual group object delivered
34:23
in the group's map for its primary POSIX GID, even though the entry does not exist. And there are virtual groups. For example, those are fixed GIDs,
34:41
which have a local meaning here. So all members of all groups who have log few rights are merged into this virtual group. And you can use this, for example, to give read access to VAR log messages or something for the group, which is pretty handy, actually.
35:09
And the AE host also syncs the SSH authorized key to the system. And there are some specific features, like if you are doing a PAM request,
35:22
then it also sends the so-called LDAP session tracking control to the LDAP server. And then the IP address of the SSH client is really appearing in the lock of the open LDAP server, which
35:41
is pretty handy for security audits and forensics. So and the enrollment, each client needs a password. And if you do this with SSD or with another daemon,
36:02
basically, if you are deploying your machines, for example, with a pixie boot and you have auto just installation or pre-seed or Kickstarter or whatever, the machine comes up. And most people then do something like have a generic local log in there
36:20
and then log in with this local log in and apply the configuration afterwards after deploying the machine. So obviously, for some time, you have a gap in your security policy. So you have a freshly installed machine. And in your directory, there's the security policy defined for it, but it's not applied yet because you didn't do the configuration step.
36:45
So my goal was to say, OK, the machine starts. It knows where to connect the directory servers, where to query for the security policy, but it cannot do this yet because it doesn't have
37:01
its password yet. So what I'm mainly doing is just a Psoido PAM log in with a Psoido user. And if you do this, it checks the password you provide here against its own host password. And if that matches, it just writes it down
37:22
into its own configuration. And this is pretty neat because if you ever try to do something like a secure domain join of a host with Active Directory, for example, you always have this little gap between setting up the machine and the need for a local administrative account
37:44
before you can really apply the configuration enforcing the security policy. And that's nice here because you don't have the gap. You just fire the host password on it. And if it's right, the host password, then it will be used. OK, so security by design is possible.
38:07
It's painful for all people involved, especially also the user. Sometimes it's painful. You have to encourage people to use it. You have to teach them.
38:20
And of course, some backing of the management regarding budget helps. And for me, one of the conclusions of this project is I'm now running this open source project for quite a while. I'm having a lot of ideas what to do. But I'm always very cautious not to break security promises
38:45
I did before. So I have to discipline myself not to add a feature which defeats another security promise I made before. So that's the conclusion.
39:01
OK, some links, documentation. It's not so bad, the docs. And there's also an online demo. You can right-click there. And some more information about the two-factor authentication. Yeah, and that's it.
39:22
Do you have any questions? Yeah, thank you. You mentioned in one of the first slides two different groups, visible groups and login groups also.
39:43
I think, yeah, the login groups in the middle and visible groups below them. What's the difference? Why do you distinct? The motivation was that on some servers, you just need, for example, the possibility in group map
40:01
data. But people do not have to log in. For example, file servers, plain file servers. They need the NSS map data to enforce the local file restrictions, but you don't have any need to really log on this NFS server,
40:23
for example, with SSH. And technically, the distinction is that being a member in a login group gives the host read access to the SSH public key attribute,
40:44
to the SSH authorized key, and gives search access to the PVD changed attribute. So actually, a host can really determine whether somebody has login right by just searching the user with a certain filter.
41:01
I show an example.
41:30
So this is a very stupid configuration how to do a simple mod LDAP integration for Apache. And in this step, if you're logging
41:41
in with this simple HTTP basic authentication, the Apache web server has to map your user ID to the distinguished name of the directory entry before checking the password. And so it has to search for the user account.
42:06
And basically, if you add this filter component to your search filter, the search will only return a result if the user is in one of the groups in the login groups.
42:24
And so you don't have to configure anything site specific here. You're just saying, you just advise the LDAP server to follow the ACLs. And then you get a result if it has the login right or not.
42:42
And this is pretty handy. Yeah, that answers my second question. Is a login only limited to SSH login or limited for any service login? Yeah, for any service login. OK, thanks. Always provided that the service can use LDAP in any way.
43:01
So any other question? OK, who of you are member of the open source heroes?
43:23
OK, two of you. Last year, I did a proposal for the open source project because I heard that the free IPA instance running, used as a base for the logins to the infrastructure systems,
43:44
is running on Fedora. So my proposal was to replace this because it runs also on open source. So I mean, it's just two of you.
44:02
Let's discuss later whether that's an viable option for you. And yeah, any more questions? OK, thank you for your attention.