 I'm going to talk to you about identity management. Yes, we do have a full room. So yeah, are there any seats left? No, OK. Everyone can give it up for Fraser Tweedle. Yeah, it's nice to have a packed room. And yeah, I'm Fraser. And I'm going to tell you about FreeIPA, which is an open source identity management solution. So I'm a developer at Red Hat, where I work on FreeIPA. And in particular, on the DogTag certificate system, which provides all the public key infrastructure needs for FreeIPA. And I have a development blog. The link is up there. And my Twitter handle is hack-by-door. So I'm going to introduce identity management. And in particular, FreeIPA as a solution for enterprise scale identity management, an open source solution, of course. So we'll have a look at the features of FreeIPA a little bit about how to deploy it. We'll have a look at the overall architecture of FreeIPA and the client components. And we'll conclude with a look ahead to what's on the roadmap. So identity management, what is identity management? Well, Wikipedia defines it as, and I'll just read this out because it's quite a mouthful, identity management, or IDM, describes the management of identity principles, sorry, individual principles, their authentication, authorization, and privileges within or across system and enterprise boundaries with the goal of increasing security and productivity while decreasing cost, downtime, and repetitive tasks. So there's a lot in that. Let's break it down a bit. Identities are entities like users, hosts, and services within an organization. Authentication are your concerns where you need to gain a degree of assurance that someone is or something is what it says it is. So these are passwords for authenticating users, two-factor authentication systems, certificates, single sign-on, and so on. Authorizations are the policies concerning identities and what they are or are not allowed to do within a system. And that concern only becomes relevant after you have authenticated an entity. And finally, the management concern is about how to manage these policies and identities in an efficient and scalable way. So if you're a small company, maybe 10, 20 people, you might have one sysadmin, he can manage it all by hand. You scale up to a large organization with thousands of users, thousands of machines or services. That is not a situation where you're going to want to have to scale the number of sysadmins. You have looking after these things linearly. That's a waste of money and there's a lot of duplication of effort. So some of the technologies in this space include LDAP, which is the Lightweight Directory Access Protocol or Directory Service. Kerberos, which is an authentication protocol where there's a shared secret on a key distribution center or KDC. And hosts and users can authenticate to that system. X509 is the public key infrastructure you're probably familiar with for securing the web and also email services and many other network protocols. So it describes a system of digital certificates where you can have chains of certificates, each verifying other certificates below it. So when you get a certificate chain, you can verify it right back up to a root certificate. DNS is the domain name system for binding names to network addresses. And NFS is the network file system for mounting user home directories on different machines they log into, for example. So that's identity management. What's free IPA? Free IPA stands for identity, policy, and audit. We do do identity and policy. We don't do the audit thing. So when the project was started, audit was intended to be part of it. At this point, it's been realized that it's better handled by other software, but it's still there in the name. It's a centralized identity management suite. So by centralized, we're not talking about a single server. When you deploy free IPA, there are a variety of topologies with replication agreements between different servers. So you have the ability to scale out and have redundancy in the system. Centralized really means that one deployment of free IPA is going to manage identities and policies for one system, and outside systems aren't really going to be consulting a different free IPA system for information. So it's not a federated system. Typically, one organization will have one deployment or one set of deployments of free IPA, specifically for that organization. It has a simple web UI and a simple command line interface. So we want to make it easy for people to manage the identities and the policies. Got to hide the complexity and also provide users self-service for some facilities where an organization might decide, well, we can let individual users manage, for example, their SSH public keys. Simple deployment is a priority of the project. How simple? It's one command to install or to deploy rather the server, free IPA server. And it's one command to install a client and enroll it in a domain when you've already established a server. And finally, we have Active Directory integration. So that is quite important because many organizations already have a lot of their identity data in Active Directory. They're probably not going to change wholesale across the industry anytime soon. So for free IPA to be successful, we need ways to integrate with Active Directory, but allow organizations to avoid a duplication of effort and avoid having separate identity silos. So if you have a largely Windows organization, but they need a Unix group or individual people using Unix hosts or providing Unix services, we want ways for people who are clients of the Active Directory realm to be able to get tickets for accessing the Unix services and vice versa. OK, so that's just a screenshot of the web UI. So it's, well, I've seen worse UIs than that one. So just to prove to you that it doesn't look horrible. Well, I don't think it looks horrible. UX people might disagree. So the components of free IPA are the 389 directory server, the MIT Kerberos KDC, the dog tag certificate system. And that's the component that I mainly work on. Although we do support other CAs, the Apache HTTPD is used to serve up the web UI and the APIs. And we also have bind for the DNS component. So onto the features now. In authentication, we have password policies, so things like patterns that, you know, that old thing, you've got to have so many special characters in uppercase and wellcase, and also password expiry policies. Kerberos ticket policy, so how long is the ticket issued for? Kerberos over HTTP. So for users who might be outside the corporate firewall or on a mobile device where only port 80 and 443 are accessible, you can actually have a Kerberos proxy running on one of those widely accessible ports. And they can do Kerberos over that port. One-time password, so we have native hash-based and time-based OTP, or external OTP systems like your, what's the company with the tokens, RSA Secure IDs and that sort of thing. And we also have the free OTP app for Android and iOS, and this is a free replacement for Google Authenticator. We also have some special commands for writing keys into UB keys if you want to use a UB key-based OTP system. We also do authorized keys management for SSH. So for a server where users will be logging in with SSH, if they provide their public key, then on those servers, instead of the regular authorized keys file containing the keys of people that are authorized to log in there, it can consult a database and look it up in the free IPA system to decide whether that key is known. And this is also subject to authorization checks. So we can authenticate a user, so yeah, we recognize that key. Now let's do some checks using PAM to determine whether they actually are allowed to access this host. For users and groups, we have automatic group membership rules, sudo integration, so you can bind particular commands and command groups to the user groups or the users that are allowed to execute those programs via sudo, SE Linux user roles, the auto mount capabilities, and role-based access control, which is more of a free IPA specific concern, so who is an admin for free IPA itself. Hosts, host groups, and net groups, so similar to user groups. We have automatic host group membership rules, one command host enrollment, so again this is this ease of deployment and ease of enrollment. The IPA client install command is used to, once you've yum installed or apt get installed, the free IPA client, just issue that command, enter a few, answer a few questions like where's the host or whatever, or via DNS auto discovery without prompting. It will install the client and enroll it in the domain. Host-based access control rules and SSH known hosts management, so similar to the authorized keys. There's a facility in open SSH where instead of just checking a flat file, it can go and look it up in a database and this can avoid the first time a user connects to a server. There's always that prompt, here's the key fingerprint and everyone just says yes and never checks it. So with the known hosts management, no one gets prompted. It's already known within the system. Services are first class identities in free IPA. We provide Kerberos key tab management and certificate provisioning via the certmonger tool, which also has the very nice feature of automatic renewal. So as the expiry date of a certificate approaches, certmonger can go and perform a new certificate request to get a newer certificate. So users don't encounter warnings about expired certificates when they're accessing servers that are authenticated with the X509 key infrastructure. So on the client side, we have SSSD, which is the system security services daemon. This connects a Unix client to one or more central identity stores. It's available on most Linux distributions and also on FreeBSD. And it supports free IPA. It also has special knowledge of Active Directory and some of Active Directory's features, but it can also talk to a bare ALBAP server. So this is something we use when you install free IPA clients. SSSD is configured, but you can use SSSD independently of FreeIPA, and it is a useful program. It provides credential caching and offline support. So if someone goes offline or if your KDC goes down, they can still log into systems and get work done. It works by providing PAM and NSS responders that know how to talk to the identity store and can look up names, can perform authentications, and so on. And there's also a D-Bus API, but that's not a stable API. And it's not very well fleshed out yet, but if you have use cases for that, we definitely want to hear about it. And we'd like to see what people can do with a D-Bus API for SSSD. So Active Directory integration, as I mentioned earlier, is an important part of what will make FreeIPA successful. The main feature for FreeIPA and Active Directory integration is the cross realm trust. So we used to do synchronization, but that is actively discouraged in the recent versions since cross realm trust arrived. So this allows you to manage your users, for example, in Active Directory and manage hosts and services on Unix systems and Active Directory users. So users of systems that are enrolled in the Active Directory domain can access the resources in the FreeIPA domain. POSIX attributes can be stored in Active Directory, or you can use views, which I don't know a lot about, but I think it basically does some transformation of Active Directory data or attributes into something that's understood in the POSIX domain. There's simple configuration, so there's no Active Directory specific host or service configuration. It can all be configured just by issuing commands on the Unix system. There's no data synchronization, and there's no additional software needed on the Active Directory machine. For all clients that don't have SSSD, or maybe an older version of SSSD, without the Active Directory support, we also provide what we call the legacy compliant, the legacy client compatibility tree. So this basically provides a tree with, I can't remember the name of the schema, but there's an RFC that defines the appropriate schema. With that tree, we can intercept binds and look up whether that user is an Active Directory user or a FreeIPA user. If they're a FreeIPA user, we then perform the bind against the FreeIPA directory tree. But if they're an Active Directory user, we authenticate them to Active Directory via the local that is running on the server, so local to the FreeIPA server, SSSD instance. For server deployment, we support Fedora, Rallon, CentOS. It's quite recently, I think, about October last year, available on Debian and Ubuntu. But this is less supported. So there are a few people working on that, but most of the developers on FreeIPA working on Red Hat systems, and indeed, many are working for Red Hat. So Fedora, Rallon, CentOS, these are our main focus. So there's one command to install the server, IPA server install, and you answer the questions it asks you and wait a few minutes as it sets it all up and you're done. All your infrastructure will be up and running, and you can begin enrolling clients in that domain or hitting the web interface and adding users, adding groups, adding pseudo rules, whatever it is you need to do. It is slightly more work to set up a replica. That's two commands. For client enrollment, again, a single command. You can answer some questions, wait a few minutes, and you're done. There's also auto discovery by DNS, which means you have to answer fewer questions. There's options for unattended install, and what IPA client install does is it configures SSSD, configures PAM, NSS, SSHD, all of these services that are working together to provide this nice experience for users of the domain, gets set up when you run IPA client install. There's also some integration with provisioning systems, including satellite or spacewalk, which is the upstream of satellite. Roundy with the open LMI, which I think is open Linux management infrastructure, and the form and smart proxy. I actually don't know a lot about these technologies, but maybe some of you do, and people on the mailing list do, so if you have questions, ask and you shall find. So the architecture, at a high level, we have the free IPA server with the LDAP directory, and the certificate authority, KDC, DNS, the HTTP server, all of these services talk to the one LDAP directory. You have an administrator that can administrate the domain using the web UI or the command line tool or the APIs. And we have hosts that enroll in the domain, typically using IPA client install, which will configure SSSD and related services, but possibly using the LDAP compatibility tree in an old client, so without SSSD. SolarisBox can be configured as a client of a free IPA realm, free VSD, open VSD, most unique systems you can set up. We have a Active Directory domain with Active Directory hosts and users, yeah, question. Specifically, you are trying to avoid siloed, effectively that doc. You mentioned before you were trying to avoid siloed user stores, but effectively you have got to because you've got AD and you've got the LDAP store on your free IPA, so I'm kind of confused by that. Yeah, so that's a great question. So what we want to avoid is duplication of identity data. And so we want to avoid silos with the same identity data existing in them. So if you have a situation where you have your users in Active Directory, you might have services running in the free IPA realm and only the only user identities you might have over there are administrators for the unique service and that sort of thing. But your main organizational identity data would, well, it's common, very, very common, to have an Active Directory domain with most of your organization's users in there. But you might have a Unix group with just a few Unix admins and servers there, but everyone needs access to those servers. In that situation, you'd set up a cross realm trust. Yes. You mentioned there's a better duplication of data between free IPA and Active Directory. Thus free IPA has the mechanism to detect if the, let's say, the user has already been existing on the Active Directory and also there's an instance like the PKI as well. If there's already an existing PKI record for that user, does pre-IPA check it or does it have the mechanism to do so? Okay. So if I understand correctly, your question is, is there any facility for detecting whether a user exists in both Active Directory and free IPA? As far as I know, there isn't, but it wouldn't be hard to write a script to go through and check for that sort of thing. Okay. For SSSD, the architecture, so we have a free IPA server over here which includes the identity data and also the authentication services. This here, by the way, is one host, so the clients are programs on the same host that SSSD is running. SSSD provides the NSS responder for name lookup and PAM for authentication and authorization, so clients talk to NSS and PAM according to their needs. These go through the cache, which provides the offline and credential caching and then these talk to the domain provider and the domain provider routes requests for general identity data or for authorization or authentication services accordingly. And yeah, there's just way too much detail in that diagram to explain, but if you want, you can snap a picture of that now, but the slides will be available online anyway. Okay, so the roadmap. Short-term efforts, so these are things that are efforts that are well and truly underway. In many cases, these have already been released in free IPA 4.1, which is available on Fedora 21 and there's also a copper to use free IPA 4.1 on Fedora 20. So DNSSEC support, CA certificate renewal, so automatically renewal, not just of the service certificates, but actually the CA certificate and pushing the new CA certificate out to clients. Back up and restore scripts for your free IPA domain data. The updated web UI, so the screenshot I showed earlier is actually the updated UI. If you use free IPA 3.0, something, then the UI is a little bit, well, it doesn't quite look as nice as what you saw. Improved permissions and fine-grained read access is a big improvement that landed in free IPA 4.0. Integration with the Red Hat support portal for rail subscribers and these features are available in SSSD 1.12 and free IPA 4.1 and this is being considered for release in rail 7.1. Longer-term efforts, so these are efforts that are just starting or we're laying the groundwork for these, enforcing stronger authentication for select services. So if you imagine a situation where you have some services that maybe are not particularly sensitive, so you say anyone who has a ticket-grinding ticket from the KDC, anyone who's authenticated, can get a ticket to access those services. But you may have more sensitive services and you might want to enforce a policy that says, well, if anyone wants to talk to this service, we want to make sure that they've authenticated using two-factor authentication. Currently, there's no way to make those policy decisions. The Kerberos KAMAC facility, which I think stands for container, something multiple-max, one of which can be the authentication-indicated data, will be used to implement the ability to define and make these policy decisions. The Kerberos authentication for mobile devices, so we had some people looking at actually getting the Kerberos client running on Android devices. I'm not quite sure where that work is at, but there was definitely some work in that area. DNSSEC improvements, so our DNSSEC support is fairly basic at this point. DNSSEC is gonna allow key rotation and revocation and that sort of thing. Smart card login for SSSD, so instead of authenticating with a password, you can insert a smart card to your computer and use that for authentication. Customizable X509 certificate profiles. At the moment, we only deal with server certificates. This will allow people to define new profiles for servers and also down the track lead to user certificates. So we'll be able to provision certificates for users to, for example, access a VPN server or whatever it is you may wish to do. These can be short-lived certificates as well. So you can say, well, we want a certificate for them to authenticate to a VPN service rather than having to have them do it manually using an OTP or a passphrase. So we can provision a short-lived certificate, maybe an expiry of one hour. They can use that to connect to the VPN. One hour passes, that certificate will never accept it again. And finally, the password vault, which is a user-accessible, secure key and password store. So this is something that will allow free IPA administrators to provide to their users as a self-service. And it's basically a free IPA front-end to what we call the dog tag key recovery manager. So a secure secret store. We have efforts to integrate with CloudForms. We also are playing with Docker, which is so hot right now. So we're looking at SSSD running in containers. So free IPA client in a container for other services in that container to use, and also running the free IPA server in a container. We have some methods in OpenStack, particularly with Keystone for authorization. BarberCan, which is the OpenStack secret store. We're looking at a back-end for BarberCan using free IPA. It would dog tag and the designate DNS component. Also, with OpenShift v3 coming up soon, which I'm sure some of you will have seen in Katie's talk yesterday, we're gonna do another round of integration. So we have free IPA support there for people who want to deploy OpenShift within their enterprises. Calamari, which is a self-management platform. And yeah, insert your project here. Maybe your project is one that could benefit from integrating with free IPA. If so, let's start the conversation. So adopting free IPA. The GNOME infrastructure team recently adopted free IPA for all of their identity infrastructure. There's a really good blog post. It's actually a series of blog posts, but start here. And you can learn about what their requirements were, why they decided on free IPA, and then in subsequent posts what was their journey of adopting and migrating to free IPA. You might have knowledge of or be involved in an open source project or community that is currently suffering from a proliferation of identity silos containing the same identities over and over again. If that's so, then you might also benefit from migrating to free IPA and we would love to talk to you and find out what your requirements are and work out how we can help you do that. There's a demo where you can go and play with the web UI. You can enroll clients to see what that experience is like and to use some of these features. Information about how to use the demo is at that link. It's sandboxed and it gets blown away every 24 hours and started afresh. You could put some really cool stickers on your laptop. If you think free IPA is a cool and an interesting project. We've also got Dog Tag and SSSD and OpenShift, which I didn't talk about really, and Docker, which is so hot right now. I've got stickers. There's stickers out on the Rego Desk and I've got spares if they run out there. So in conclusion, free IPA is an advanced open source enterprise identity management solution with a focus on ease of use and deployment. So the goals of the ease of use and deployment, of course, to reduce the cost of managing your identity infrastructure. The Active Directory integration helps avoid duplication of effort and duplication of data for enterprises who are already using Active Directory but have a need to run Unix services as well. So you might have a project or know of a project that can benefit from integrating with free IPA or benefit by adopting free IPA for your identity infrastructure. We'd love to talk to you if that's the case. Resources is a free IPA website. There's a page on how to adapt your web applications to use the authentication and the authorization facilities provided by free IPA. It's a number of mailing lists including the below traffic interest list which is used primarily for release announcements. The user's list which is general discussion and questions and of course the deval list which is where we make the design decisions and do patch review and so on. FreeNode, free IPA channel, and there's also a blog, what do you call this, a blog role, blog planet? I don't really know. But Planet Free IPA, that's a blog aggregator. Also SSSD, if you're just interested in that, we have Fedora hosted slash SSSD which is the main website and mailing lists of course and IRC and whatnot. Thanks to Demetri and Martin who made the diagrams because I really suck at that. And now we have time for questions. Yes. Thank you. One thing that I wonder about is how to secure the Kerberos server. Like, if it sort of holds the crown jewels, how do you actually, you need to make it available for configuration management and so on. And it needs its own management. And I have wondered about how this, you prevent people from just say, well, I'll just go and get all the everyone's accounts from here. Yeah, that's a good question. I'm not nor have I ever been a systems administrator. So I don't have any firm answers for you there. If you were just in Olivier's talk, and maybe he would have some good advice for you in terms of securing UNIX servers. I mean, the Kerberos server. It's a play-go, just tell me. Yeah. That's nice that you have that one. Sure, I mean, same with the certificate authority. You know, you need to secure the private keys. So even though credentials aren't typically traveling across, across the wire in an X509 public key infrastructure, or in network services that are using X509 to secure their communications, you still have those high-value targets. My understanding is SSSD will also talk directly to Active Directory, is that right? That's correct, yep. And in fact, you can configure it to have knowledge of multiple identity stores and authentication services at the same time. Know that IPA client install will specifically configure SSSD as a client of a free IPA domain, as well as configuring the other related services. Hi, just wanted to ask quickly about in the current IPA setup, you can't avoid the kind of domain admin problem you have in AD, where you have to have someone that has the rights to do absolutely anything with the directory that they like. And you kind of can't avoid that. However, is there any intention on the roadmap to provide a bit of segregation in those lower levels of administration about what they can mess with? So for example, you may have two vendors that you're using to run Linux infrastructure. You don't wanna have to duplicate multiple free IPA stacks for each of those vendors, but you wanna be able to limit their ability to add SUDU rules for each other's hosts or provision users in a way that would allow them to leverage the fact that they're using a shared directory. Yeah, great question. I'm not entirely sure on that. I know that you can delegate administration responsibilities, but I don't know if you can delegate them in a way whereby the responsibilities are branched into separate branches where people with the same responsibility or the same level of authority in terms of what they can do. But that's authority only applies to a particular sub-branch of the organization. I'm not quite sure. The mailing list would be a great place to find more about that. So this is kind of a bit of a two-part question. If you can get, oh, can you get Windows clients to auth to the free IPA server, even though the user account sits on the Windows AD box? Or does that require basically setting up the, like Windows machine to basically instead of being trust by the Windows AD, the Ignite should go to free IPA. But this is leading to the question of can you use free IPA to phase out AD in the one seen was hit? Yes, I believe you can configure Windows clients as clients of free IPA domain. That's not a particularly common use case, or at least it's not something that I'm aware of people doing very much. What was the first part of your question? Can you... What was that one? Basically, can you put in free IPA to be able to phase out a Windows AD server? So if you've got Windows clients as well as like units clients as well, can you...? You're right. Well... You're going to be able to answer the question. Yes. It looks like he wants to answer. Cool. Again, I've never been an active directory administrator. I don't know a whole lot about that side of the system. It's usually what people want to find out about those. So I'm sorry, I can't give you a direct answer to your question, but... Yeah, Andrew Bartlett would be great to speak to and the mailing list as well. Yeah, I work for a software development company. A lot of the developers run Macs. Has any of this been tested with OSX? I don't know if it has been tested with OSX, but given that OSX is Unix and you could definitely compile and run this software on it, maybe not as is, but it wouldn't be hard to patch it, I think. So if not today, then... Yeah, I'm sure with a small amount of effort it would be doable. Okay? Great. So I might hit you up for that information and then send it to the chat list or something afterwards. Yeah. It's about the Windows group policy on an AD. I know it's quite hard on the Linux or Unix side to implement group policy. Is there any future plans to populate the group policy on the Windows domain that's used by the Windows clients to pre-IPA because you've mentioned that the pseudo commands for the clients of pre-IPA can be controlled as well. So instead of doing it manually, I know, like for example, installing application and shared printer on the Windows AD through group policy is easy. But with Linux Unix, we can do that through infrastructure management, puppet ship, so exporting the existing or populating the existing group policy on the Windows AD domain to be used by pre-IPA would be great. Yeah. So I think that that is what the views feature is intended to be used for. So where you take group attributes or other attributes of users on the Active Directory side and then kind of creating on the fly the corresponding policy on the free IPA side that the service will then reference the Unix service. Is that what you were meaning? No. The AD group policy file is a separate module in Windows AD that you could export that into some one file format and I don't know how you could convert that or use it on pre-IPA if there is any future plans to do it or to support that. Okay. Yeah. I'm going to have to punt on that one. I'm afraid as well. It's not an area I know much about. Yeah. The mailing list will be, so the user's list would be a great place to ask these sorts of questions. And I promise you there are people there who will understand much better than I do what your question is and be able to give you a firm answer. Yeah. We can have Linux clients directly as clients for AD. So what's the benefit of putting free IPA into the mix? Why should we authenticate against free IPA instead of going directly to AD? Yeah. Again, it comes to the situation of you're an organization with your identity infrastructure in Active Directory, but maybe you have a need for a Unix group or you have a Unix group, they're going to want to manage their servers and their administrator accounts in the Unix way. So they can deploy a free IPA server and enroll clients in that domain. And you set up a cross realm trust. And so it's more about the situation where you have separate groups that want to manage the identities that they're responsible for in the ways that make sense for those platforms and being able to interoperate between those two different domains without duplicating identity data. I suppose not. All right. So we have run out of time now. If you do have more questions, I'm sure you can go and ask questions outside and take your questions out there. But on behalf of the LCA team, we'd just like to thank you again and give you a small gift. It's a huge round of applause. Thank you.