 We ask you to turn off cell phones and stuff like that to avoid noise. I guess we can begin. So I'm Simo Sochi. I've worked for Red Hat and about 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? 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 match a complex problem. And the problem is the problem of managing identity management and managing identity and enterprise. 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. And the target is system administrator for seven to 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. But 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 like anything that is more than 10 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 identity management. Of course there have been for many years, 20 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, 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 these kind of expertise is not that common while there are probably many of you that really knows how to manage one or many of this system 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 is not easy and indeed it's never common. When I go to enterprises I find that they use various proprietary products for that reason they cannot trust one or two administrators to build the load of the whole organization especially if it's very big. So they do things like using, if they are kind of a Windows shop today they tend to use AD active directory, they use NTFOR domains or an e-directory before if they've been a mostly unique shop they may still be using CAA trust, all these kind of products and the problem is that 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 it's a very effective method to lock you into their business so if you want to have a fully free environment without 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 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 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 on the fly is a very hard task so let's try to dive into what is the identity management problem what we faced when we start this project were basically more or less these needs we need a single source for identities because duplication is usually confusion we came from a situation 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 the Linux space some organization used NAS or NAS+, very few used LDAP and the reason for not using this system were depending mostly on the history 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 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 your credential anymore while single password is kind of 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 most of the servers you connect to 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 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 two common password or that the machine that's actually inside of this network actually really applying the policies that come down from your network and finally you want a single point of management you want to have a comprehensive view you don't want to have multiple systems you have to touch just to create a user identity you don't want to go in one place to create a user and give it for example it's a positive attribute it's 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 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 be synchronized in 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 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 case when you have a system that is not able to replicate and you also have the problem again of integrating interfaces because you have different components that are completely using 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 so let's see what are the free IPA components that we decide 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 S++ that have been used in the past but we found that they were not actually able to do what we needed to do so why a directory but we need the storage mechanism to keep data entities these storage mechanisms need to be able to perform fine ground access control and why is that if you look at the classic UNIX or Linux authentication methods you see that the data storage in the very basic configuration is the ATC pass-by file and ATC shadow file for example so we have actually even on the single clients two places where you have some information and the reason is that the original mechanism, the ATC pass-by was not able to have fine ground access control on each and every field of the file so when a 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 to see all the other information 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 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 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 hash is for your password the can see it can only see other attributes like the shell the home directory can't see the hash of other users or his own hash we also need to be able to organize the entity and other group relationships that's why why is that again if you look at the relational learning system you also have a third file which is the ATC group 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 don't realize that the user doesn't exist anymore in pace with the etc so we wanted a system where 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 but it's really part of the identity and if you look in the kernel you see that actually the kernel has a structure where it is the user ID and the group ID and exactly for that reason because group IDs are the 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 information and can do that very efficiently it's very efficient for services it's less efficient for writes so when you 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 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 whatever server you usually use goes down you can immediately connect from your client to another server and keep having information from the server other reasons why we chose LDAP is that it's a standard although it's not a standard that can change and indeed some implementation are less adhering to the standard that we would like but more or less 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 you just have to introduce some new schema you can attach a 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 is that it's really part of the protocol that you can find additional attributes they are not interested in when a client search for some information usually it doesn't only specify how to reach the entry which attributes it is interested in so that means that you can really extend the information about the user in the same place but all the other information is without having to create new information that is stored 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 new operations of LDAP if you need something that cannot be simply solved with a query and we actually do that in free IPA and it's very flexible because of these reasons so second part of the identity is usually authentication 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 and what we decide to use is Kerberos for a number of reasons so we say that one of the things we need to do when you use an identity manager system is trying to provide single sign on as much as possible that allows you to provide services for a multitude of servers without having the user to re-enter his password again and again which is something that is both unknowing 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 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 and Kerberos allows you to do single sign on 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 and 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 the time 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 credentials because of this it allows also administrators and users to basically 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 from the server connect to another one and still carry on your credentials so you can delegate again and again and again without having to directly connect to each server 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 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 to it but it kind of interoperates with standard MIT Kerberos implementation it's also to some degree extensible it's not like LDAP where you can plug in whatever you want but there is still a very active community around Kerberos MIT also 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 in most Kerberos implementations and this is going completely away but it's very easy to introduce new encryption algorithm and the protocol is built so that it can actually provide the clients with a list of encryption algorithms that are accepted from the server and vice versa so that basically clients and servers can negotiate the best encryption algorithm available at any given time so we use Kerberos in free IPA it's the predominant method to do authentication with one user free IPA because unfortunately many applications still rely on a username and password parody we also provide the ability to use classic LDAP binds where you connect to LDAP, provide username and your password and you authenticate it but this is certainly not what we advise you to use normally so back to the components list up to this point seems very simple 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 an organization you have to deal with DNS and NTP 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 are not using CluxQ to try to use an old ticket again so the maximum CluxQ between a client and the server can be 5 minutes so the client 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 the network time protocol so that all the client servers in your organization basically are synchronized and they all share the same cloud the other components there's not strictly necessary but actually for any real implementation you really want it is DNS the reason is that 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 QDC for a ticket for a specific service name because the name is part of 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 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 client and server register in DNS so when one client try to connect to another server it knows what is the other server name and can ask the QDC please give me a ticket for that server the client as well need 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 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 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 use directory to store his own name so that DNS can use the directory as a storage but usually you want to connect them so that each host 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 things together so 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 organization you want to see that 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 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 servers are but you also want to provide the client with at least the basic security policies it has to use where it can accept a connection authenticated or unauthenticated where 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 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 clients some information can be downloaded from the directory some information still at least in Linux systems is really embedded in configuration files so you need another method to get this information into files that's what we call policies another component that we think is important is WebUI and admin tools and the way we built the admin tools in the WebUI is through a web server a batch in this case and an XMLRPC 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 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 that the clients connect to the right web servers not to many of the middle 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 and 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 a report in the central location if there is something that is not working correctly or if there is penetration attempt or whatever so that each single piece can report in a 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 components that we decided to use inside FreeIPA? okay, we started with Fedora Active Server and MIT Kerberos we are at Apache on top with a bunch of modules that we use by default Modern SAS instead of Modest-SSL 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 and it has FIPS, one FIPS to compliance and it's a library that is being used more and more inside Fedora there is actually a project to push all upstream projects to try and use and assess instead of OpenSSL or other solution like new TLS we also need more out Kerberos to be able to use Kerberos authentication in Apache and we will see why we use Mod Proxy for the web interface we use Turbogears and we also use Python because Turbogears use Python but use Python also to implement the XMLRPC interfaces we also had to implement custom Fedora Active Server plugins and we did all the set of tools also in Python for the admins this is basically the stack you see on the server side in V1 on the client side we use in V1 NSS LDAP and PAM Kerberos 5 on Linux 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 that's in gray is we don't have a proper 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 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 why it is 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 see immediately from here is that you don't see the familiar OU-Eagle people or OU-Eagle group in the base GNS actics that you might normally see in other LDAP data implementations we decide not to do that way and we decide to basically put all the user and group information under the GN-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 and make it simpler basically to prevent access to part of the directory where normal clients shouldn't have access and this came handy immediately after V1.O was released because we found out that unfortunately Solaris does not support in 2009 RFC 237 base RFC 237 base 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 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 information that way so what we did is we built a plugin in FDS that basically creates a virtual subtree called CNEagle Compact and basically it presents the same information you have in CN accounts, CN groups but with the old RFC 237 schema so if you have a legacy client a Solaris client, a very old Linux client some old AAX or HPX client that still doesn't support 237 base 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 used to okay so besides the directory how did we basically integrate Kerberos in the directory as I said before one of the problem 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 create we used the LDAP plugin of the MITKDC and we store all the Kerberos information into LDAP as well actually we store the user credential for the user entry and then we just use ACIs to prevent any other user or the user himself to directly access those credentials another piece that wasn't necessary though is the password plugin because we wanted to allow people to also use a classical LDAP bind for legacy applications we needed to make sure that the LDAP was actually represented the same password that you use in Kerberos that you can use the single password approach in that case so basically what we did is railroad IPA capacity creating a new K-pass with the daemon specifically for IPA they basically rewrote any password change request on the K-pass with the protocol to LDAP and use the LDAP password operation the same happens if you use directly 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 K-indit 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 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 go back into the Kerberos database and try to delete it as well the user is relaying the same et cetera so the other parts of the management interface they are also completely dependent on the directory server of course as 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 the idea is to create basically a proxy approach what authentication is done by a model of Kerberos on Apache and then every single query is proxy to the GUI which is a process that runs only locally and the GUI gets actually Kerberos credentials even though it's not able to use itself to authenticate the user and use the XMRPC 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 so if you make something new basically you have to also create common liability at the same time and we basically get the credentials into XMRPC and we use your Kerberos credentials that are delegated to us to connect to the directory server 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 XMRPC or to the GUI you have to provide your own user ticket that ticket because it we use delegation is what it used to authenticate the XMRPC piece to the directory so it's not possible structurally not possible for someone to basically hijack your GUI 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 go on because I have only 10 minutes so this is the web interface with v1 just wanted to show something it's very simple very basic but does the task be needed add find users on the right add find groups, delete groups manage policy which are just password policies in v1 we also have a cell service page where a user can change some of his own attributes again because we have ACIs we can allow a user to easily change some of the information that are in the 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 his own group ownership for example we also have of course a common line interface there are a lot of commands more than 20 and if you really are not satisfied by using abstractions you can even go and use all that yourself if you know what you are doing although I don't think you really want to do that 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 but it's also the whole thing about installation so what we built within the project was actually for example all set of install dealers for both the server and the client if you want to try IPA and I suggest to you you try them and 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 it asks you for a directly manager password which is kind of the root password of the system something you don't use for normally except for very specific operations and then ask you for an admin user password and the admin user is the default user who has a set of privilege like you can create other users can create groups, change policy and stuff like that once you do that the job is done the server is installed, configure all the components configure and system restarted and basically you have a working IPA server you can immediately serve out tickets to the admin user or any user you create with the admin user so we basically tried to make it very very simple to install without all the problems you have trying to understand how to configure LAP, how to configure Kerberos how do I configure any other service there 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 basically all you have to do is install a client and there too it's not that complex we have a client installed tool that will configure NSSL.Pump Kerberos 5 it works on Red and Fedora not other system at this moment but it's very simple to configure just NSSL.Pump Kerberos compared to what is to configure the whole server thing and you can use basically any client that supports Kerberos authentication to connect to the server and do management through WebUI or through admin tools the other thing we needed to add is multiple servers as we said one of the problem 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 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 to all servers also meant that we could avoid using the Kerberos server application server KEPRA and instead of having one master Kerberos server many slaves basically we have multiple master Kerberos servers as well again setting up a replica is quite easy IPA replica prepare run on the master it generates a file that is encrypted so you can safely transport it over the network and you just get this file on the new server you run IPA replica install and you basically just do it it will take all the information in that file generate a new 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 add multiple servers you can also use IPA replica manage to change the replication agreements so if you have four servers you can use it to add a new replication agreement that have a fully matched replication we test up to and by testing in 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 so if you DNS service records you basically can tell the clients this is the list of KDCs this is the list of LDAP server connect to any of them and they will tend to spread the load around that was version one and as I told you it lacks policy and audit so what do we have in version two well in version two we have also some few interesting things the thing that I'm working at the moment is SSD system security services daemon plus an IPA plugin that daemon is basically 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 do with an SSD LDAP or on Kerberos which are very bad thing because if you lose your network temporarily you can't get any more user information so application may get stuck when they do a simple thing like IPW 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 and we have also managed interfaces for that we are introducing host based access control central imagine the rules are stored in LDAP so that you can say user can connect to machine bar between 8 and 10 Monday to Friday nobody else or even at the service level you can say foo can connect to bar to SSH but not not just hambo or HTTP stuff like that we are introducing roles in v2 that's a bit complex let's go on because I have very little time left and we also have now the daemon both on the server 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 are also trying to have better user interface so we have sessions with people that are expert in UI design to try to make it a bit better a bit edgy with more interactive stuff like that although we keep the same code again to also provide all the common line stuff DNS integration it's another thing we are working on a new LDAP bind plugin and gssdc to provide the option to do dynamic updates a registration authority which can connect a certification authority to request certificates and other services and LDAP so this is the picture of v2 it's not 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 yeah just one word on client machine identities what we lack in v1 was 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 machine gssh 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 have if you're interested I have thought later on in the Fedora session I will talk about without this and audit as well two pieces the client that collects audit logs the kernel audit logs syslog as well can use our syslog to send them we will also have an option to use the NQP which is a very interesting messaging cure protocol has a very good thing that it can do store and forward so if you if your machine loses a network it can store the logs separately when an exit come back can send them you can also have routing rules so you can have an audit server that is interesting only on the subset of the logs and another one that collects all them just for storage and stuff like that in fact we have a server component that gets all the information from the clients uses Kerberos authentication to connect the client to the server so you have authentication sign and seal of the connection so you have proved that the log comes from the real client and stores them for later refuel and I have no time I wanted to just show these diagram which is the thing I'm working on I will talk about this in detail into the Fedora talk session for PM if you're interested in this component I guess we don't have time much time for questions 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 from an authentication point of view at the moment we have a synchronization between free IPA users and active directory users if you use active directory there we have on our wiki page is also instructions built by some users very good instructions if you just want to use the Kerberos side of free IPA 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 a local user and you associate that user with Kerberos credentials you can get at least your Kerberos credentials if you don't have a lot of interaction 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 made at least you have centralized authentication against IPA you can access services through Kerberos but it's kind of limited and the plan is to work with the SAMA community to basically integrate free IPAs before some point but that will take a lot of time to get started version 2 under development I have a number of pieces of this thing you're seeing here we initially try 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 the very basic pieces working sometime by the summer so we can start testing stuff in the master tree we now have all the new web UI stuff the new common 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 is being integrated so yes we are progressing but thank you