FreeIPA, Identity Management in the FOSS World
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 70 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/39514 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 200949 / 70
3
4
6
16
17
18
19
20
21
22
23
24
25
26
27
29
30
31
32
33
35
40
41
44
46
47
48
50
51
54
55
57
58
59
60
62
65
67
68
69
70
00:00
Identity managementBoom (sailing)Office suiteNoise (electronics)Product (business)MaizeSoftwareSelf-organizationConnectivity (graph theory)MereologyIdentity managementPhysical systemService (economics)FreewareServer (computing)Information securityMessage passingIntegrated development environmentSign (mathematics)Traffic reportingSingle-precision floating-point formatVirtual machineGame controllerMultiplicationComplex systemSystem administratorExergieData managementOpen sourceEnterprise architectureStructural loadBitDirectory serviceLogic gateRow (database)Social class2 (number)Data storage deviceOrder (biology)INTEGRALExpert systemWebsiteComplex (psychology)Block (periodic table)BuildingState observerImplementationWeb 2.0Different (Kate Ryan album)Point (geometry)Internet service providerSource codeProjective planeStandard deviationComa BerenicesClient (computing)Multiplication signGame theoryClosed setInstitut für Didaktik der MathematikSingle sign-onPasswordAuthenticationDomain nameWindowCASE <Informatik>Position operatorOcean currentTask (computing)NP-hardCommunications protocolOpen setArithmetic meanXMLComputer animationLecture/Conference
07:54
PasswordSocial classGroup actionComputer fileDirectory serviceField (computer science)InformationHash functionImplementationCommunications protocolView (database)MereologyAttribute grammarPhysical systemWindowGame controllerSelf-organizationINTEGRALSynchronizationSoftwareStandard deviationVirtual machineServer (computing)MultiplicationRandomizationClient (computing)Point (geometry)Single-precision floating-point formatIdentity managementReplication (computing)MathematicsTask (computing)BitConnectivity (graph theory)Data storage deviceIntrusion detection systemData structureKernel (computing)FreewareNetwork topologyClassical physicsTerm (mathematics)Mechanism designConfiguration spaceAuthenticationTheory of relativityAcoustic shadowDifferent (Kate Ryan album)Interface (computing)Set (mathematics)Distribution (mathematics)WordCASE <Informatik>Gastropod shellMeasurementEvent horizonPower (physics)SurfaceRight angleLoginResultantGame theoryPrice indexProduct (business)Execution unitNumbering schemeService (economics)Lecture/Conference
15:41
ImplementationKerberos <Kryptologie>Physical systemDegree (graph theory)Standard deviationInformationService (economics)System administratorIdentity managementConnectivity (graph theory)Server (computing)Client (computing)Key (cryptography)Multiplication signLoginData transmissionConfiguration spaceDistribution (mathematics)AuthenticationEncryptionDomain namePasswordMultiplicationGame controllerInternet service providerSingle sign-onLatent heatMereologyDirect numerical simulationSelf-organizationMoment (mathematics)Communications protocolHeat transferSoftwareSkewnessMaxima and minimaFrequencySensitivity analysisPoint (geometry)Keyboard shortcutClassical physicsCartesian coordinate systemOperator (mathematics)Electronic mailing listQuery languageSoftware developerNumberExtension (kinesiology)Archaeological field surveyDirectory serviceCovering spaceBit rateProduct (business)Coma BerenicesCarry (arithmetic)Arithmetic meanSoftware testingSign (mathematics)FreewareFilm editingQuantum stateEvent horizonINTEGRALRule of inferenceOffice suiteLecture/Conference
23:28
Server (computing)Client (computing)InformationInformation securitySlide ruleBridging (networking)Service (economics)Directory serviceDistribution (mathematics)Virtual machinePublic key certificateWeb 2.0Direct numerical simulationSelf-organizationAuthorizationData storage deviceDefault (computer science)Graphics tabletSoftwareProper mapUser interfaceCASE <Informatik>Kerberos <Kryptologie>Latent heatConnected spaceEquivalence relationComputer fileSystem administratorRow (database)Physical systemMetropolitan area networkSet (mathematics)ImplementationAuthenticationRight angleDot productPlug-in (computing)MultiplicationConnectivity (graph theory)Interface (computing)Module (mathematics)Software as a serviceProjective planeTransport Layer SecurityOpen setUniform resource locatorOrder (biology)Goodness of fitLibrary (computing)Centralizer and normalizerTraffic reportingConfiguration spaceData structureWeb serviceEndliche ModelltheorieProcess (computing)Fraction (mathematics)Existential quantificationView (database)Revision controlSpacetimeLogic gateWritingSpeciesMedical imagingPrincipal idealWordComa BerenicesWebsiteNetwork topologyArithmetic meanPhysical lawSign (mathematics)QuicksortFerry CorstenProxy serverPrice indexCovering spaceLecture/Conference
31:14
Data structureAttribute grammarPlug-in (computing)InformationClient (computing)Kerberos <Kryptologie>ImplementationGroup actionGame controllerPoint (geometry)Configuration spaceFile formatDirectory serviceMereologyReading (process)Digital photographyForm (programming)FreewareComa BerenicesSystem callGame theoryNumbering schemeLecture/Conference
33:51
PasswordUtility softwareCommunications protocolModule (mathematics)Kerberos <Kryptologie>MereologyInformation securityDifferent (Kate Ryan album)DemonDatabaseIdentity managementServer (computing)ExistenceInterface (computing)INTEGRALHash functionProcess (computing)InformationSynchronizationLine (geometry)Web 2.0Single-precision floating-point formatSystem administratorPlug-in (computing)Directory serviceMathematicsUser interfaceQuery languageSource codeEndliche ModelltheorieKeyboard shortcutClassical physicsTask (computing)Latent heatOperator (mathematics)CASE <Informatik>Turbo-CodeAuthenticationProxy serverRemote procedure callCurveMessage passingCartesian coordinate systemObservational studyGroup actionMultiplication signUsabilityFerry CorstenDiscrete element methodGoogolCovering spaceEvent horizonModal logicArithmetic progressionLecture/Conference
39:04
NumberUser interfaceInformationTask (computing)System administratorAttribute grammarWeb pageDirectory serviceGroup actionSampling (statistics)Cellular automatonParsingLine (geometry)Lecture/Conference
40:04
AuthorizationInformationRow (database)Physical systemStructural loadPasswordService (economics)Kerberos <Kryptologie>Replication (computing)Software testingServer (computing)Direct numerical simulationPoint (geometry)Default (computer science)View (database)RootPublic key certificateVirtual machineBitUser interfaceDirectory serviceReal numberComputer fileImage registrationInstallation artSet (mathematics)Keyboard shortcutPlug-in (computing)Process (computing)Computer configurationUtility softwareLine (geometry)Attribute grammarLevel (video gaming)INTEGRALComplex systemMathematicsProjective planeSelf-organizationProxy serverAuthenticationMultiplication signSingle-precision floating-point formatDemonWeb 2.0Computer hardwareHacker (term)AbstractionWeb browserRule of inferenceCentralizer and normalizerClient (computing)Identity managementConnectivity (graph theory)Combinational logicCore dumpInterface (computing)Configuration spaceGame controllerSoftwareCartesian coordinate systemOperator (mathematics)Moment (mathematics)System administratorQuery languageRevision controlMultiplicationCodeConnected spaceElectronic mailing listMusical ensembleDirection (geometry)RoutingComputer multitaskingLogic gateRoundness (object)Workstation <Musikinstrument>Data structureGroup actionCategory of beingPrice indexCovering spaceCurveNetwork topologyArmState observerComplex (psychology)Information securityCursor (computers)AreaLecture/Conference
48:32
Server (computing)Identity managementClient (computing)Beat (acoustics)Service (economics)Physical lawBlogConnected spaceSign (mathematics)Virtual machineData storage deviceDefault (computer science)Real numberInformationSubsetAuthenticationLoginRule of inferenceProduct (business)Computer configurationKerberos <Kryptologie>Kernel (computing)Connectivity (graph theory)WordMultiplication signSoftwareLecture/Conference
50:21
Machine visionWikiData structureMoment (mathematics)Multiplication signElectronic program guideConnectivity (graph theory)Network topologyNumberSoftware developerPoint (geometry)PlanningDiagramLine (geometry)Software testingConfidence intervalService (economics)Workstation <Musikinstrument>InformationShape (magazine)Group actionInteractive televisionData conversionCovering spaceFreewareWindowCASE <Informatik>AuthenticationKerberos <Kryptologie>State of matterRevision controlINTEGRALWeb 2.0DemonDirectory serviceLimit (category theory)SynchronizationView (database)Lecture/Conference
53:10
XML
Transcript: English(auto-generated)
00:07
Ask you to turn off cell phones and stuff like that to avoid noise. I guess we can begin. So I'm Simos Ochoa. I work for Red Hat and about
00:22
two years ago we started thinking about this project called Free IPA and we actually got to implement it. So I guess the first question for everybody that doesn't know it already is what is Free IPA and what does it stand for?
00:42
So Free IPA stands for Free Identity Policy and Audit and those are the three legs that compose our product. The purpose of the project is to make simple to manage accomplished problems and the problem is the problem of managing identity management and managing identities in the enterprise.
01:00
The means are try to use as much as possible standard components, standard protocols so that it's easy to implement because you used documented protocols and also it's easy to reuse already existing components and clients in your organizations. The target is
01:24
system administrator for seven to a hundred years and what we try to accomplish is to have a system that is certainly complex but also easy enough to use that you don't have to be an expert in every single component of the system.
01:46
The next question is why should I care about something like that? Well the point is that every organization that is not a very small organization
02:01
like anything that is more than ten users need to manage users and resources inside it. So if you look at the IDM landscape what you see is that so far only proprietary software was available for organizations that need to do some complex
02:22
identity management. Of course there have been for many years, twenty years and more single building blocks that were available like MIT Kerberos various LDAP implementations like OpenLDAP and other LDAP servers, all kinds of web servers
02:44
different kind of policy and auditing servers but to be able to have a comprehensive and complex system integrated you really had to be an expert in every single of these components and this kind of expertise is not that common
03:03
while there are probably many of you that really know how to manage one or many of these systems, being able to really manage them all in a way that can be easily applied to an organization that has multiple sites or multiple administrators
03:22
is not easy. Indeed it's never common. When I go to enterprises I find that I use various proprietary products for that reason and they cannot trust one or two administrators to build the load of the whole organization especially if it's very big. So they do
03:42
things like using, if they are kind of a window shop today they tend to use AD Active Directory, they use NT4 domains or E directory before. If they've been mostly unique shop they may still be using CAA Trust all these kind of products and the problem is that
04:05
these products basically held the case of your organization they have the very entry point, they have the user identity they have the credentials, so basically is a very effective
04:20
method to lock you into their business so if you want to have a fully free environment you actually need also a free identity management system so that you can have not only your free servers but also a complete free environment where you use them
04:40
and I believe a lot in security plus freedom and by freedom here I mean free software open source, you can inspect it but also being able to switch to someone else if you are not satisfied by the security that your current security provider provides you when you have a closed
05:00
source solution it's very difficult, it's extremely difficult actually to try to move something else, you're basically completely at the mercy of the organization that provides you that solution because basically every single machine in your organization is tied to that solution and try to change it
05:20
on the fly is a very hard task so let's try to dive in into what is the identity management problem, what we face when we start this project were basically more or less these needs, we need a single source for identities
05:45
because duplication is usually confusion, we came from situation of many customers where people basically used to replicate the user from server to server to server and tried many ways to keep them synchronized especially in
06:02
the Linux space, some organization used NIS or NIS plus very few used LDAP and the reason for not using this system were depending mostly
06:23
on the history of the organization but some felt that having to depend on external network services was not trustworthy enough at the time or was too complex or was too fragile the second problem or the second need is single sign on
06:43
or single password which are two quite different things, by single sign on I mean you don't have to put your password anywhere so you can authenticate on your client machine and go and connect to any single machine in your organization without having to provide
07:02
your credential anymore while single password is second class or fallback position where at least you have the same password everywhere but you still have to provide it on every server or on most of the servers you connect to
07:22
now to achieve single source of identity and single sign on or single password you also need a single data store for identity and reporting because you need to be sure that everything is working as you expect and you need to be able to report what's going on in your organization once you
07:43
spread authentication or identity in the whole organization need to be able to know that actually your machines are in compliance with the organization policies that when you change a password somewhere the strength is controlled so that you don't use a too
08:01
common password or that the machine that's actually inside of this network is actually reapplying the policies that come down from your network and finally you want single point of management, you want to have a comprehensive view, you don't want to have multiple systems you have to touch
08:21
just to create user identity, you don't want to go in one place to create a user and give it for example its POSIX attributes like the user ID and group ID and stuff like that and then go to another system to set the password and maybe another system to set some other attributes of the user or preferences or the policies
08:41
you just want to go in one place so that you can see everything about the user in one single comprehensive view. So what are the implementation problems to achieve that? So one problem is either synchronization or integration where when you have two distinct components that need to
09:01
be synchronized and some organizations that want to use both Windows and Unix for example there's a problem synchronizing the users on the Active Directory side with whatever you had on the Unix side. In other words distribution of data or credentials when you have a system where you distribute or where you
09:20
try to synchronize users you have also the problem of distributing any change that comes in one of these systems so that the others keep being synchronized. You have single points of failures in some cases when you have a system that is not able to replicate and you also have
09:40
the problem again of integrating interfaces because you have different components that are completely use completely different interfaces. You have a fragment system where you have to learn different syntaxes or different methods to change the information. So that's a challenge for organizations.
10:02
So let's see what are the three free IPA components that we decided to use to try to solve these problems. So the first one is the directory and by directory I mean LDAP. There are other directories like NIS and NAS Plus that have been used in the past but we found that they were not actually
10:20
able to do what we needed to do. So why a directory? So we need the storage mechanism to keep data entities. These term magnets need to be able to perform fine grained access control. And why is that? If you look at the classic Unix
10:41
or Linux authentication methods you see that the data storage in the very basic configuration is the ATC password file and ATC shadow file for example. So we have actually even on a single client two places where you have some information and the reason is
11:02
that the original mechanism, the ATC password, was not able to have fine grained access control on each and every field of the file. So when password attacks started to happen in the real world, people realized that having the password hash in the same file that everybody needed to access
11:21
to see all the other information was not a good idea because you were not able to prevent people from seeing the password hash. So the shadow file was created. At this point we have already a synchronization problem. What happens if I change the password file and I forget to change the shadow file? Of course there are tools
11:41
to avoid that but that was a problem and that problem was also in NIS because NIS is basically taking the file you had on your local machine and trying to distribute them again on multiple machines but it didn't change how these files behaved. So in
12:02
a system like LDAP instead, what happens is that you can set access control instructions for each and every attribute. So you can say, if you log in as an administrator, you can't see or you can't change, usually you don't see it, the hashes for your password. But the user that comes in can only see other attributes
12:22
like the shell, the home directory, can't see the hashes of other users or his own hashes. We also need to be able to organize identity and other group relationships. Why is that? Again if you look at the relational Linux system you also have a third file which is ATC group.
12:42
ATC group contains group information. But again there we have a synchronization problem because you may create a user in ATC password and not put it in the right group so you may change groups and not realize that the user doesn't exist anymore. So we wanted a system where
13:01
in a single tree we could have both users and groups because groups are part of the identity of a user. A group may define what you have access to, what machines you have access to, or what resources on the machine you have access to. So it's really part of the identity. And if you look in the kernel, you see that actually the kernel has a structure where there is
13:21
the user ID and the group ID and exactly for that reason because group IDs are an integral part of your identity. Another good point is that we need to distribute information across all clients and LDAP is really good at that. LDAP has been built exactly to distribute
13:41
information and can do that very efficiently. It's very efficient for services, it's less efficient for writes so when they make changes it's a bit slower but that's not important because the main task for an LDAP server is to distribute information. And finally
14:01
and that's to avoid a single point of failure you really need to be able to replicate information on multiple servers so that if your main server or whatever server you usually use goes down you can immediately connect from your client to another server and keep having information from the server.
14:22
Other reasons why we chose LDAP is that it's a standard, although it's not a standard that can change and indeed some implementations are less adhered to the standard that we would like but more or less
14:41
at least for all the basic functionality, LDAP is quite standardized and all the clients we know can connect to a random LDAP server without problems. It's extensible both in the sense that you can extend the information that is tied to an identity user or group
15:01
you just have to introduce some new schema attaching new object class to a user entry and you can attach new information to that user entry and unless a client is very badly written, what happens is that the client doesn't mind if there is more information because the LDAP is done
15:21
is that it's really part of the protocol that you can find additional attributes they are not interested in. When a client searches for some information usually it doesn't always specify how to reach the entry but also which attributes it is interested in. So that means that you can really extend the information about the user
15:41
in the same place where all the other information is without having to create new information at the storage. It's also extensible in the sense of what operations you can do in LDAP. LDAP has extended operations so basically you can customize and create
16:01
new operations over LDAP if you need something that cannot be simply resolved through a query and we actually do that in FreeIPA and it's very flexible because of these reasons. Second part of the identity is usually authentication
16:22
they go together. You have an identity, you have some credentials, how do I use this credential to prove that I am who I am? What we decide to use is Kerberos for a number of reasons.
16:42
We say that one of the things we need to do when you use an identity manager system is try to provide single sign-on as much as possible. That allows you to provide services for multiple servers without having the user to re-enter his password again and again and again which is something that is
17:00
both annoying for the user because he has to basically stop his work and try to remember his credentials and re-enter again. It's also usually insecure because if you make the user think that it's normal to provide your password for anything you do, it's very easy to convince him to provide
17:21
the same password to a server that is not under your control meaning that it makes the user willing to give the credentials even to servers that are not trusted, which is bad. Kerberos allows you to do single sign-on
17:41
authentication. Kerberos is a ticket-based system where you basically contact at login time a key distribution center that will give you back a ticket and that ticket basically allows you to get other tickets to access services without having to provide your real credentials anymore.
18:01
The good thing is that this ticket expires very quickly. Usually it's between 6, 8, 24 hours depending on the configuration of the KDC, which means again that even if someone can somehow get hold of your ticket, he's not able to use it for more than 8 hours, 24 hours
18:20
until the ticket expires because there is never transmission of your credentials which are required to basically acquire a new ticket to go on and further use other people's credentials. Because of this it allows also administrators and users to basically
18:41
go from server to server and through delegation it also allows you if you use something like SSH to basically get into a server delegate your credentials to the server and from the server connect to another one and still carry on your credentials and you can delegate again and again and again without having to directly connect
19:00
to each service you need. So you basically can jump from server to server and carry on your credentials with you by just carrying your ticket granted ticket. It's a very test standard. It's been developed for many years at MIT and it has been actually implemented in basically all
19:21
the identity management system around there. The most popular system that basically made Kerberos available to everybody is actually Active Directory which is based on Kerberos as well. And their implementation is almost standard. They have some things added
19:41
to it but I cannot interoperate with a standard MIT Kerberos implementation. It is also to some degree extensible. It's not like LDAP where you can plug in whatever you want but there is a very active still very active community around Kerberos. MIT also
20:01
created recently the MIT Kerberos Consortium to be able to keep going on and develop MIT Kerberos. You can actually introduce quite easily new encryption algorithms. Recently AES was introduced
20:21
in most Kerberos implementations and that is going completely away. But it's very easy to introduce this new encryption algorithm and Prodigal is built so that it can actually provide the clients with a list of encryption algorithms that are accepted from the server
20:41
and vice versa so that basically clients and servers can negotiate the best encryption algorithm available at any given time. We use Kerberos in FreeAPA. It's the predominant method to do authentication when you use a
21:03
FreeAPA but because unfortunately many applications still rely on a user name and password. We also provide the ability to use LDAP binds, classic LDAP binds where you connect to LDAP, provide user name
21:24
and your password and you're authenticated. But this is certainly not what we advise you to use normally. So back to the components list. Up to this point it seems very simple.
21:40
Basically there are just two components. You have the LDAP server and the Kerberos server and it seems like it shouldn't be a big deal to build something like this. But unfortunately this is not all. As soon as you introduce Kerberos in your organization, you have to deal with DNS and NTP.
22:01
One thing about Kerberos is that it's very time sensitive. Because Kerberos releases tickets that are available only for a short period of time, it actually needs to make sure that you're not using clock skew to try to use an old ticket again. So the maximum clock skew between a client and the server can be
22:24
five minutes. So the reason clients and server can have a slightly different notion of what exactly this moment is in time but not too much. So what you really need in an organization is to introduce NTP, the network transfer protocol so that all the client servers in your organization
22:44
basically are synchronized and they all share the same clock. The other components is not strictly necessary but actually for any real implementation you really want is DNS. The reason is that
23:03
when you use Kerberos to connect to a service and you want to authenticate to that service, you need to know what is the DNS domain name of that service. And that's because when you ask for a ticket, you need to ask the KDC for a ticket for a specific service name because the name is part of
23:24
the service principle, basically the identity of the service. So if you don't have a way basically to connect to a server using a name you can't get the ticket to connect to that service unless you ask the user to provide it somehow and that's
23:43
something you don't want to do. So basically it turns out that when you implement Kerberos, you want to have DNS and you want to have all the clients and servers registering DNS so when one client tries to connect to another server, it knows what is the server name and can ask the KDC please give me a ticket for that server. The client as well
24:09
needs to be taught how to basically use it so you have to teach the client how to use LDAP to get users, you have to tell the client how to use Kerberos to log you in and you have to
24:21
tell the client where is the NTP server and where is the DNS server to use to be able to do both things. This also means that usually you want to connect the DNS and the directory
24:40
it might just be that you use host files on the directory in case you don't want to use a DNS server or just that the client uses the directory to store his own name so that DNS can ask the user directory as a storage but usually you want to connect them so that each host
25:02
is connected to his own name in the DNS so when you create a new machine and a new service principle you also can link these two things together so that the name of the machine is linked to the service principle of the server and that's because again when you look at the whole
25:23
organization you want to see if each server actually has Kerberos connection or not in an easy way so you want to keep everything in one place to connect all the dots As soon as you start thinking about that you also realize that you have to have a method
25:42
to configure the client at least for the very basic things like where do I connect to get information partially that can be resolved through DNS and SRV records so that in DNS you can tell where the directory and where the Kerberos server are but you also want to provide the client with
26:02
at least the basic security policies it has to use whether it can accept a connection authenticated or unauthenticated whether it can accept the connection from a specific user for a specific server and stuff like that so as soon as you start having the network as your padding you really
26:22
want to have a method to configure the client as well in a centralized manner so when you change something in your organization you don't have to run machine by machine but you have an automatic distribution of this information to the client some information can be downloaded from the directory some information still at least in Linux systems
26:41
is really embedded in configuration files so you need another method to get this information and put that into files that's what we call policies. Another component that we think is important is web UI and admin tools and the way we build the admin tools and the web UI is through
27:03
a web server, Apache in this case, and an XML RPC interface so basically web server becomes a component of this picture because you need to manage the web server you need to make the web server available to clients and that means also you probably need a certification authority because when you talk to a web
27:23
server and you want to have a second channel usually you need an SSL certificate a TLS certificate so immediately you start having the problem that when you have multiple servers and clients you basically need to make sure the clients connect to the right web servers not too man in the middle
27:43
servers that can spoof your connections and that means you need a certification authority of some sort or at least certificates from an external certification authority so that the client can trust the SSL certificate without user intervention.
28:02
Finally, once you have all these pieces you really need a way to know that everything is running properly that there are no bridges in the security so you basically need an auditing system that can connect to all these pieces and report in the central location if there's something that's not working correctly or if
28:23
there is penetration attempt or whatever so that each single piece can report in the central place where you can basically collect and compare data from all these systems to know that your solution is working properly. Okay, so what are the actual
28:45
components that we decided to use inside FreeIPA? We started with the order of two servers and MIT Kerberos, we added Apache on top with a bunch of modules that we use by default, modern SaaS instead of modern SSL
29:01
is used and NSS is the nested security services library which is a very good SSL TLS library which is used because it's also certified it has FIPS 1, FIPS 2 compliance
29:21
and it's a library that is being used more and more inside Ferrara there is actually a project to push all upstream projects to try and use and assess instead of open SSL or other solution like new TLS. We also
29:41
need more out Kerberos to be able to use Kerberos authentication in Apache and we will see why we use ModProxy. For the web interface we use TurboGiz and we also use Python because TurboGiz use Python but use Python also to implement the XML RPC interfaces.
30:01
We also had to implement custom Ferrara directory server plugins and we developed a set of tools also in Python for the admins and this is basically the stack you see on the server side in V1 on the client side we use in V1 NSS LDAP and Palm Kerberos 5 on Linux
30:25
more or less all Unix systems have equivalents and we basically use what is available on these systems. What we have as we don't have in gray is we don't have a proper
30:40
CA in V1. What we do in the default installation is to create a self-signed CA and expose the certificate through the web server. It's not ideal. We don't have policies in V1 and we don't have the audit piece. So all the things you saw in the last slide
31:07
basically the red pieces and the green one are absent. The green is self-signed so it's not really there. This is the directory structure we use
31:21
Why is it important? Because even though LDAP tend to be very flexible also need to have some conventions so that you can actually use the directory in the same way. One of the things you can
31:40
see immediately from here is that you don't see the familiar OU-Eagle people or OU-Eagle group in the base DN sacrifice that you might normally see in other LDAP data implementations. We decide not to go that way and we decide to basically put all the user
32:00
information under the CN-Eagle accounts subtree because that way we could more easily add access control instructions on the one subtree and keep other subtrees like CN Kerberos or CNETC where we put a lot of configuration outside of these ICIs
32:21
and make it simpler basically to prevent access to part of the directory where normal clients shouldn't have access. This came handy immediately after v1.0 was released because we found out
32:41
that unfortunately Solaris does not support in 2009 RFC 2307-bis RFC 2307-bis is what we rely on because instead of using the very old member UID attribute where in a group you just name the user by name, we use the member
33:01
and member of attributes where you basically put the DN of the user into the group entry and unfortunately Solaris is the only one that is not able to read the information that way. So what we did is we built a plugin in FDS that basically creates a virtual subtree called CN-Eagle compact and it basically
33:22
presents the same information you have in CN accounts, CN groups, but with the old RFC 2307 schema. So if you have a legacy client Solaris client, a very old Linux client, some old AX or HPX client that still don't support
33:40
2307-bis, what you can do is basically point these clients to use the compact subtree to find group information and they can find group information in the format they're used to. Okay, so besides the directory how did we basically integrate
34:01
Kerberos in the directory? As I said before, one of the problems is synchronization or integration information. We wanted to avoid having a different database for Kerberos because we would have to synchronize that database with the directory. So basically what we did, we used the LDAP plugin of the MIT KDC
34:21
and we store all the Kerberos information into LDAP as well and actually we store the user credential in the user entry and then we just use ACIs to prevent any other user or the user himself to directly
34:41
access those credentials. Another piece that was necessary though is the password plugin and because we wanted to allow people to also use a classic LDAP bind for legacy applications, we needed to make sure that the password hash in LDAP was actually
35:02
represented the same password that you use in Kerberos so that they can use the single password approach in that case. So basically what we did is rewrote IPAK password creating a new K password daemon specific for IPA that basically rewrote any password change request
35:21
on the K password protocol to LDAP and use the LDAP password operation. The same happens if you use the LDAP password operation against the LDAP server, you go through the password plugin. The password plugin basically generates all the Kerberos material for Kerberos. When then you do kinit
35:41
Kerberos, the KDC basically gets that information out of LDAP, extract from ASN1 the secrets and is able to authenticate your packets and give you back Kerberos TGT. So basically the directory is the source of all the information. We don't have a
36:01
synchronization problem because the information is kept within all the user data. So if a user is deleted, also all his Kerberos material is deleted immediately. The Kerberos server will not be able to give again a ticket for a user that doesn't exist. We don't need to basically go back into the Kerberos
36:21
database and try to delete it as well when a user is already in the same. The other part is the management interfaces. They are also completely dependent on the directory server of course. As
36:41
I told you before, we use three main modules in Apache and that's because in V1 we had a problem with convincing the turbo gear stack to use Kerberos authentication. So what we did is to create basically a proxy approach where the authentication is done
37:01
by a model of Kerberos on Apache and then every single query is proxied to the GUI which is a process that runs only locally. And the GUI gets actually the Kerberos credentials even though it's not able to use them itself to authenticate the user and
37:23
use the XML RPC interface so that we keep ourselves honest. Everything that you see from web interface is the same thing that's used also from the admin tools so that they all use one path only. You don't have to duplicate functionality and you're sure that if you test something with one of the two, it's the same thing.
37:44
So if you make something new in the web UI, basically you have to also create a common line utility at the same time. And we basically get the credentials into XML RPC and we use your Kerberos credentials that are delegated to us to connect to the directory server.
38:04
And that's another layer of security because basically it means that the web server doesn't have any privileged access to the directory. To be able to access any data in the directory, you really need to have your own Kerberos ticket. So when you connect to
38:24
XML RPC or to the GUI, you have to provide your own user ticket. That ticket, because it will use delegation is what is used to authenticate the XML RPC piece to the directory. So it's not possible, structurally not possible for someone
38:43
to basically hijack the web UI and try to perform administrative tasks unless you really have the administrator ticket. So you really need to be administrator before you're able to do anything like that. And yes, so let's
39:05
move on because I have only ten minutes. So this is the web interface for v1. Just wanted to show something. It's very simple, very basic, doesn't do much, but does the task we needed at find users
39:21
on the right, at find groups, delay groups, manage policy, which are just password policies in v1. We also have a self-service page where a user can change some of his own attributes. Again, because we have ACIs
39:41
we can allow a user to basically change some of the information that are in directory. For example, you may say I want to allow the user to change his own phone number so that other users can get an updated phone number without having to go through an administrator to change that information. But we want absolutely to prevent him to change
40:01
his own group ownership, for example, stuff like that. We also have, of course, a command line interface. There are a lot of commands around there, more than 20. And if you really are not satisfied by using abstractions
40:20
you can even go and use LDAP yourself if you know what you're doing. Although I don't think you really want to do that. You usually will break your own installation. But as you can see, this seems a very complex system. And we said we want to make it simpler to manage. Yes, the web interface can help. That's also the whole thing about
40:42
installation. So what we built within the project was actually, for example, all set of install utilities for both the server and the client. If you want to try IPA, and I suggest you try them in
41:01
V1.2 especially, all you have to do is basically install the packages, run IPA server install, and you get three questions. It asks you what is the real name for Kerberos, and it also suggests a default based on your DNS name, the DNS name of the machine.
41:24
It asks you for DirectMeManager password, which is kind of the root password of the system. It's something you don't use normally, except for very specific operations. And then it asks you for an admin user password, and the admin user is the default user that is created in the system that has a set of privileges, like
41:44
you can create other users, you can create groups, change policy, and stuff like that. Once you do that, a good job is done. The server is installed, configured, all the components are configured and the system is restarted, and basically you have a working IPA server. You can immediately serve out tickets to the admin user, or any
42:03
user you create with the admin user. So we basically try to make it very, very simple to install without all the problems you have trying to understand how to configure LDAP, how to configure Kerberos, how do I configure any other service there.
42:20
It's really as easy as that. So what would you end up to once you have done that, you have that core that now seems much simpler. It has all the components we described, but they are contained in that thing, and basically all you have to do is install a client, and that too, it's not that complex. We have
42:43
a client install tool that will configure NSS LDAP AMP Kerberos 5 and it works on Red and Fedora, not other systems at this moment, but it's very simple to configure just NSS LDAP AMP Kerberos compared to what is, to configure the whole service. You can use
43:03
basically any client that supports Kerberos authentication in the browser to connect to the server and do management through web UI or through the admin tools. The other thing we needed to add is
43:21
multiple servers. As we said, one of the problems is a single point of failure. What happens if my server has a hardware failure? If it goes down, the whole organization can't work because my users cannot authenticate. And that's also one of the reasons we choose directory server instead of something like
43:41
OpenLDAP. Directory server has a very mature multi-master replication, and it can basically replicate all the information at the attribute level on all the servers so that when you change something on any of the servers, that information is replicated immediately
44:00
to all servers. It also meant that we could avoid using the Kerberos replication server kprod and instead of having one master Kerberos server and many slaves basically we have multiple master Kerberos servers as well. Again, setting up the replica is
44:20
quite easy. IPA replica prepare run on the master generates a file that is encrypted so you can safely transport it over the network and you just get this file on a new server, you run IPA replica install and you basically just do it. It will take all the information
44:40
in that file, generate a new server, install all the components and start running. From that point on you have two servers that are replicating all the information. If you have multiple server you can also use IPA replica manage to change the replication agreements. If you have four servers you can use it to add a new
45:00
replication agreement so you don't have a fully matched replication. We test up to and by test I mean QA, up to four servers they can replicate completely even the other cross there and you can use DNS records to basically spread the load among all clients.
45:24
So if you DNS service records you basically can tell the clients this is the list of KDCs, this is the list of LDAP servers, connect to any of them and they will tend to spread the load around. Okay, that was version 1
45:40
and as I told you it lacks policy and audit. So what do we have in version 2? Well in version 2 we have also some few interesting things. The thing I'm working at the moment is SSD, System Security Services daemon, plus an IPA plugin. That daemon
46:00
is basically a client agent that is able to combine Kerberos authentication, LDAP queries, policy queries in one piece, do caching, do offline operations. These are all things you can't do with NSS, LDAP or AMP Kerberos which are very bad things because if you lose
46:20
your network temporarily you can't get any more user information so application may get stuck when they do simple things like get PW name which asks for information for the user. We are creating a policy infrastructure where we have a policy process process on the client also called by the daemon
46:41
and we have also management interfaces for that. We are introducing host-based access control central management and the rules are stored in LDAP so that you can say user foo can connect to machine bar between 8 and 10 Monday to Friday, nobody else.
47:01
Or even at the service level you can say foo can connect to bar through SSH but not to Samba or HTTP, stuff like that. We are introducing roles in v2 so that's a bit complex, let's go on because I have very little time left and we also have an allied daemon both on the server
47:24
and on the client. A new web UI as you see we had to build a kind of hack in v1 where you have a proxy stuff like that, we tried to solve that, we are also trying to have a better user interface so we have sessions with people that are expert in UI design
47:41
to try to make it a bit better with more interactive stuff like that although we keep the same code again to also provide all the common line stuff. DNS integration is another thing, we are working on a new
48:01
LDAP bind plugin and GSS to provide the option to do dynamic updates a registration authority which can connect a certification authority to request certificates and other services so this is the picture of v2, it's not
48:21
very different from the previous one but you can see a few more things that we ask and a few more pieces in the core. Still we try to keep it simple from the management point of view. Just one word on client machine identities, what we lack in v1 was
48:40
by default having an identity for the machine and that's very important because you want to really be able to use Kerberos also from the machine to connect to the server to get data in an authenticated way and you want to be able to by default connect to another
49:01
machine using SSH and Kerberos without having to manually create a host principle and install it manually on the server so we do that through the new client policies, we discuss them a bit if you're interested I have a talk later on in the
49:21
Fedora session, I will talk about this and audit as well, two pieces, the client that collects audit logs, the kernel audit logs, syslog as well, you can use rsyslog to send them we will also have an option to use eNQP which is a very interesting messaging protocol, has a very good thing that it can do store
49:44
and forward, so if your machine loses the network it can store the logs separately when it has to come back, you can send them, you can also have routing rules so you can have an audit server that is interesting only on a subset of the logs and another one that collects all them just for storage and stuff like that
50:01
and in fact we have a server component that gets all the information from the client, uses Kerberos authentication to connect the client to the server so that you have authentication sign in seal of the connection so you have proved that the log comes from the real client and stores them for later review and I have no time
50:24
I wanted to just show this diagram which is the thing I'm working on, I will talk about this in detail in today's Fedora talk session at 4pm if you are interested in this component, I guess we don't have much time for questions
50:40
maybe one, okay so the question is Windows integration and state integration too, that's a very interesting question the problem with Windows is that they actually assume a lot of things from an authentication point of view
51:03
at the moment we have a synchronization between free IPA users and active directory users if you use active directory we have on our wiki page also instructions built by some users, very good instructions if you just want to use the Kerberos side of free IPA
51:22
to do authentication, the problem is there is that Windows will never connect to LDAP to get user and group information so what you do in that case is basically you create local user and you associate that user with Kerberos credentials so you can get at least your Kerberos credentials, if you don't have a lot of interaction
51:42
maybe you have just a Windows desktop for some special purpose then maybe having group and other information is not that important you can use it, at least you have centralized authentication against free IPA, you can access services through Kerberos, but it's kind of limited and the plan is to work with the
52:01
Samba community to basically integrate free IPA Samba for some point but that will take a lot of time version 2 under development I have a number of pieces of this thing you're seeing here
52:20
we initially tried to shut for release early this summer, I don't think we will make it it's really a lot of work to add other pieces but we are confident that we can have at least very basic pieces working sometime by the summer
52:41
so we can start testing stuff. In the master tree we now have all the new web UI stuff, the new command line Tilly stuff that Jason has built, and we have the SSD tree which is going on the policy work has started as well, we have some stuff there, we have a basic daemon that is being integrated
53:01
so yes, we are progressing