Re: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
On Mon, 2014-03-10 at 23:06 +, Nordgren, Bryce L -FS wrote: > > > In the default case IPA, will automatically allocate a non conflicting > > range to > > AD SIDs and pa SIDs to UIDs automatically. however if you want to use posix > > Ids stored in AD then yes, you will have to take care manually to avoid > > conflicts. > > A perhaps doable, more applied thesis still requiring a substantial > bit of work: > > Posit a successful collaboration ecosystem that organizations are free > to join or leave at will. Each realm must be free to use UID/GID of > their choice without coordinating with all potential collaborators. > The combination of UIDs/GIDs presented to individual machines still > must not collide. > > I think this could happen in IPA, assuming that all local machines and > services authenticate with Kerberos. IPA would have to allocate a > "foreign principal" record whenever the KDC was presented with a > cross-realm TGT for a local service from a "new" foreign client (that > may be tricky). IPA could manage the UID space for its own realm. Sssd > would no longer need multiple realm entries and all relevant > "id_provider" info could be synthesized at the realm level by IPA. This is what we basically do with AD trusts if you do not configure the trust to go and fetch Posix Ids from AD and is the default case :-) I see no problem doing the same with another IPA trusts once we have such a thing. > Effectively, the unique identifier for all external principles is > username@REALM, with all the previously mentioned renaming problems. Not necessarily we can do algorithmic mapping (like we do for SID->UID with AD trusts) and maintain the foreign ID as the actual identifier. > Local principals have their numeric id. But admins still shouldn't > rename principals because they will cause problems for their > collaborators. > > Or, each machine could do it. It's a matter of deciding what the > integration point is for cross-realm operation. That's pretty well > defined for Kerberos (the KDC), and for the id provider (sssd). > Trouble is, they're different integration points. > Well for IPA it will not be a big deal, once we offocially support trusts these trusts will be sssd subdomains and the configuration is fetched from IPA. > > Actually the solution to avoid capaths on clients is already planned, and > > it is to > > stop having clients try to discover topology on their own at all. Clients > > should > > always communicate with their KDC, and the KDC will issue referrals as > > appropriate. Once you do this capaths can be dismantled for the clients, the > > KDC will care for handling topology information. > > I take it this is a reading assignment for RFC6806. :) I shall dive in. Indeed. > > One small problem remains: how do I find the KDC if the realm name of the > > realm does not match the DNS domain name ? That is something that can be, > > perhaps resolved with some additional PA-DATA on the referrals if there is > > no other way. > > Yeah. Also, the DNS domain name of a service may not match the DNS domain > name of it's home KDC... That's not a problem, just a capath routing. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
> In the default case IPA, will automatically allocate a non conflicting range > to > AD SIDs and pa SIDs to UIDs automatically. however if you want to use posix > Ids stored in AD then yes, you will have to take care manually to avoid > conflicts. A perhaps doable, more applied thesis still requiring a substantial bit of work: Posit a successful collaboration ecosystem that organizations are free to join or leave at will. Each realm must be free to use UID/GID of their choice without coordinating with all potential collaborators. The combination of UIDs/GIDs presented to individual machines still must not collide. I think this could happen in IPA, assuming that all local machines and services authenticate with Kerberos. IPA would have to allocate a "foreign principal" record whenever the KDC was presented with a cross-realm TGT for a local service from a "new" foreign client (that may be tricky). IPA could manage the UID space for its own realm. Sssd would no longer need multiple realm entries and all relevant "id_provider" info could be synthesized at the realm level by IPA. Effectively, the unique identifier for all external principles is username@REALM, with all the previously mentioned renaming problems. Local principals have their numeric id. But admins still shouldn't rename principals because they will cause problems for their collaborators. Or, each machine could do it. It's a matter of deciding what the integration point is for cross-realm operation. That's pretty well defined for Kerberos (the KDC), and for the id provider (sssd). Trouble is, they're different integration points. > Actually the solution to avoid capaths on clients is already planned, and it > is to > stop having clients try to discover topology on their own at all. Clients > should > always communicate with their KDC, and the KDC will issue referrals as > appropriate. Once you do this capaths can be dismantled for the clients, the > KDC will care for handling topology information. I take it this is a reading assignment for RFC6806. :) I shall dive in. > One small problem remains: how do I find the KDC if the realm name of the > realm does not match the DNS domain name ? That is something that can be, > perhaps resolved with some additional PA-DATA on the referrals if there is > no other way. Yeah. Also, the DNS domain name of a service may not match the DNS domain name of it's home KDC... Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
> But let me say I am not at all against having thesis' that explore some of > these > theoretical questions, however one need to understand that the deliverable > may end up being something that cannot be implemented or that it would > require a long time to do so. As long as that is clear everything is game. If it was a "lock", it wouldn't make a good research topic. ;) Deliverable could be an I-D which could eventually turn into an RFC at worst. At best, the student could adapt topology discovery algorithms from IP routers, adding in "directionality" and bindings between realm and dns names. Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
On Sun, 2014-03-09 at 01:28 +, Nordgren, Bryce L -FS wrote: > IPA supplements (or hopefully will supplement) AD in my environment. I > need to worry about colliding with UIDs in a directory I don't > control. IPA can't solve this problem for me. Neither can my current > LDAP solution. But machines which could generate their own > mappings...many headaches would go away. In the default case IPA, will automatically allocate a non conflicting range to AD SIDs and pa SIDs to UIDs automatically. however if you want to use posix Ids stored in AD then yes, you will have to take care manually to avoid conflicts. > The renaming thing you brought up (within a non-UID/SID-sharing > environment) sounds like it could be a good thesis topic. "Going > forward" probably means starting to use NFSv4, which also warns > against renaming because it doesn’t use UID/SIDs. It sounds like a > necessary and present issue to address. Well, once you make the fully qualified name (user@realm) your unique identifier, renaming becomes pretty much impossibile, except at great pains (like having a 'synchronized' service that maps new name to old name and banning reuse of the old unique name for any future user). Efficiently transmitting group information also becomes a challenge, but we may decide not to care about performance :) > Assembling a functional realm containing only platform-independent > principals (could include groups, not GIDs), by extending the NFS > idmapper could be another. (Or at least ensuring that the POSIX > mappings and NFS mappings are the same...) Try the same thing on > Windows and see what the showstoppers are. Success may simplify > integration of Windows into IPA managed domains if you didn't have to > emulate an AD instance so completely. Home users everywhere may love > being able to make all their machines have the same password via a KDC > (or IPA?) running on their wireless router. Unfortunately that is not really in our hands, Microsoft tied windows clients to AD, so only Microsoft can provide 'simpler' interfaces and let the client remain fully functional. > If you're tired of this topic, how about a thesis which makes Kerberos > KDCs function more like IP routers, collaboratively and automatically > maintaining the connectivity topology between Kerberos realms? Well there are some proposal, but a thesis on this that summarize the problem and possible solution seem a really interesting topic for a bright student. > Clearly, its not the same: cross-realm connectivity (I will NOT use > the word "trust") is inherently unidirectional. Also, the mapping from > realm->dns and specific fqdns for the KDCs will need to be > communicated. Indeed we had to implement MS interfaces in IPA to communicate topology back and forth. Unfortunately 'trust' is a word you have to use any time you want to communicate information, either you trust the source or have a way to verify it is truthful ... by trusting something else :-) > The KDC could potentially communicate this topology to interested > clients, but why on earth would the clients want to know? IP routers > made UUCP bang paths obsolete, something should do the same for > Kerberos capaths. Actually the solution to avoid capaths on clients is already planned, and it is to stop having clients try to discover topology on their own at all. Clients should always communicate with their KDC, and the KDC will issue referrals as appropriate. Once you do this capaths can be dismantled for the clients, the KDC will care for handling topology information. One small problem remains: how do I find the KDC if the realm name of the realm does not match the DNS domain name ? That is something that can be, perhaps resolved with some additional PA-DATA on the referrals if there is no other way. But let me say I am not at all against having thesis' that explore some of these theoretical questions, however one need to understand that the deliverable may end up being something that cannot be implemented or that it would require a long time to do so. As long as that is clear everything is game. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
So the bottom line, if I understand this conversation so far, allowing each machine to synthesize OS-specific information from pure Kerberos principal names: * Breaks host-based authentication for file sharing (NFS3/2). * Breaks CIFS ACLs (no central SIDs) (Does it also break CIFS completely?) * Means there are consequences for renaming users/groups. * Means the machine may not be able to display a friendly user name * Means the machine will either have non-shared home directories, or require home directories be shared via NFSv4/sshfs. * Allows filesharing via NFSv4 or sshfs/swish (realm-wide, project-wide, or point-to-point) * Allows filesharing via WebDAV. * Reusable groups may not be defined. * May break Windows entirely due to a requirement for SID<->Principal name mapping on the directory server. * Centralizes password management * Allows SSO operation If one adds groups but does not attempt to manage GIDs: * Requires a directory solution (LDAP/AD/IPA) * Allows group usage on local filesystems and shared NFSv4 filesystems. > Well, we try to make it so you, administrator, do not have to deal with it if > not > rarely in freeIPA. So it shouldn't be busywork for sure. Would like to know if > anyone has a different experience and found themselves in need to tinker > for long with UIDs in an IPA environment. IPA supplements (or hopefully will supplement) AD in my environment. I need to worry about colliding with UIDs in a directory I don't control. IPA can't solve this problem for me. Neither can my current LDAP solution. But machines which could generate their own mappings...many headaches would go away. > In abstract I think there isn't much to research, this kind of operation has > been experimented for a while for real. >... > Eventually we may get to a point where multiple machines do not need to > share and synchronize much user data in the traditional way. But that time > has not arrived yet, IMHO. (Which is not to say I wouldn't want to get there, > it would be nice to get rid of this nasty problem :-) The renaming thing you brought up (within a non-UID/SID-sharing environment) sounds like it could be a good thesis topic. "Going forward" probably means starting to use NFSv4, which also warns against renaming because it doesn’t use UID/SIDs. It sounds like a necessary and present issue to address. Assembling a functional realm containing only platform-independent principals (could include groups, not GIDs), by extending the NFS idmapper could be another. (Or at least ensuring that the POSIX mappings and NFS mappings are the same...) Try the same thing on Windows and see what the showstoppers are. Success may simplify integration of Windows into IPA managed domains if you didn't have to emulate an AD instance so completely. Home users everywhere may love being able to make all their machines have the same password via a KDC (or IPA?) running on their wireless router. If you're tired of this topic, how about a thesis which makes Kerberos KDCs function more like IP routers, collaboratively and automatically maintaining the connectivity topology between Kerberos realms? Clearly, its not the same: cross-realm connectivity (I will NOT use the word "trust") is inherently unidirectional. Also, the mapping from realm->dns and specific fqdns for the KDCs will need to be communicated. The KDC could potentially communicate this topology to interested clients, but why on earth would the clients want to know? IP routers made UUCP bang paths obsolete, something should do the same for Kerberos capaths. Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
On Sat, 2014-03-08 at 01:19 +, Nordgren, Bryce L -FS wrote: > I'm not suggesting that POSIX machines stop using UIDs internally. The > local persistent map to a machine dependent representation will be > necessary. It will also be necessary on Windows machines. And on > mobile platforms. And within web applications. The shared items > (principal names) would be common to all OSes and platforms though. True, however posix information carry also other data, notably home directory, gecos and shell. If you never share home directories you can synthesize a home dire locally. And you could claim that everyone uses bash and has to change the shell on each machine independently. Gecos could also be ignored, although it is used in most desktops to show a 'nice' name when your login is something like kxy3456yt ... So yes you can probably forfeit all the user related information, however it is rarely ok to forfeit groups, so you still need to synchronize those around at least in homogeneous islands of activity. > People trying to create heterogeneous environments are already > carefully restricting protocols and applications to those which don't > require sharing a UID map. File sharing via: Samba/CIFS, NFSv4, > WebDAV, sftp (and sshfs(linux)/swish(Windows)). Logging into multiple > machines has never involved knowing your UID, and ssh key pairs makes > it more or less effortless to execute commands on another machine > whether or not your username is the same, much less your UID. Kerberos > SSO is more or less the same, but ensures that a common set of > identities are recognized. True, but the ability to successfully login does not exhaust the reason why you have a common directory, there is other data that is synchronized and shared. > Ideally, if realm admins delegate authorization to the individual > machines, the machines (regardless of OS) should be capable of > functioning with only Kerberos authentication and without any > centralized directory services. Only if you think grouping mechanism are not necessary, I do not think that's the case in any current deployment. > Minimal directory services could add group definitions via LDAP. I guess you need to define what 'minimal' would mean here :) > A full AD/IPA solution would be needed to centralize authorization > and/or enforce policy. Yet I still am not seeing the requirement for > new deployments of cross-platform environments to manage internal user > representations for a single os. I am not sure I understand what you mean by 'single os' here, they manage IDs as a single domain. Now, Posix is unfortunately limited by the fact that it has a single user space and a single group space because it was standardized when networks where rare and there were no concepts of groups of machines with homogeneous identity stores. It would be nice to fix this problem, but it is not simple to do it right, and it would require kernel support to do it right. > > However there are also issues with operations like 'renames', what > > happen when you change a user name or a group name ? You do not > > want to lose access to files when that happen, so you still need a > > unique identifier that is not the everyday name (or forbid renames). > > Presumably, you also would not want your Windows users to lose access > to files after a rename, and Windows doesn't use UIDs. Windows uses SIDs, they are perfectly equivalent to UIDs in this discussion, although they have better properties when it comes to networked machines. In fact, over CIFS, SIDs are used to set ACLs, and in general you cannot properly operate a Windows-centric domain if you do not have SID<->Name translation services provided by the Domain Controller. > You also would not want to lose access to web apps, which do not use > UIDs. Web apps often duplicate the whole user database and have their own groups, yet in enterprises they are also commonly integrated with a directory for authentication and groups. They can ignore UIDs, just like any other application, indeed. > You also don't want stale usernames to be sitting in access control > lists (filesystem based or web app based). Indeed which is why all filesystems tend to use UIDs (or SIDs for NTFS) to perform access control. Unfortunately web applications almost always do use usernames for access control, which is why renames are harder there. > Retaining UIDs does nothing to make renaming more acceptable, because > principal names are a realm-wide platform independent property, and > UIDs are not. This is debatable, but I do grant renames always need to be treated carefully, however homogeneous UIDs/SIDs allow renames to happen. Without UIDs stored in filesystems renames would simply not be possible, w/o administrators running on every single machine and operating local changes. > > This is not an exhaustive list of course, and every problem can be > probably > > worked around one way or another, however at the moment it is till > "easie
Re: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
> You *could* build a system that can work w/o synchronization, if you > carefully restrict what protocols and applications you use (think about > distributed filesystems) although you'd still need a local persistent map at > least. Backups and restore to other machines would need to be done > carefully though, and so on. I'm not suggesting that POSIX machines stop using UIDs internally. The local persistent map to a machine dependent representation will be necessary. It will also be necessary on Windows machines. And on mobile platforms. And within web applications. The shared items (principal names) would be common to all OSes and platforms though. People trying to create heterogeneous environments are already carefully restricting protocols and applications to those which don't require sharing a UID map. File sharing via: Samba/CIFS, NFSv4, WebDAV, sftp (and sshfs(linux)/swish(Windows)). Logging into multiple machines has never involved knowing your UID, and ssh key pairs makes it more or less effortless to execute commands on another machine whether or not your username is the same, much less your UID. Kerberos SSO is more or less the same, but ensures that a common set of identities are recognized. Ideally, if realm admins delegate authorization to the individual machines, the machines (regardless of OS) should be capable of functioning with only Kerberos authentication and without any centralized directory services. Minimal directory services could add group definitions via LDAP. A full AD/IPA solution would be needed to centralize authorization and/or enforce policy. Yet I still am not seeing the requirement for new deployments of cross-platform environments to manage internal user representations for a single os. > However there are also issues with operations like 'renames', what happen > when you change a user name or a group name ? You do not want to lose > access to files when that happen, so you still need a unique identifier that > is > not the everyday name (or forbid renames). Presumably, you also would not want your Windows users to lose access to files after a rename, and Windows doesn't use UIDs. You also would not want to lose access to web apps, which do not use UIDs. You also don't want stale usernames to be sitting in access control lists (filesystem based or web app based). Retaining UIDs does nothing to make renaming more acceptable, because principal names are a realm-wide platform independent property, and UIDs are not. > This is not an exhaustive list of course, and every problem can be probably > worked around one way or another, however at the moment it is till "easier" > to synchronize IDs than not ... As I see it, for a cross-platform environment, every problem must be worked around regardless of whether you have to synchronize UIDs. Managing UIDs is just more work at the end, and it might be busywork. Determining whether it's busywork or not may make a good thesis topic. :) It makes a good thesis topic because the central question is paradigm shifting: Draw a line between realm-wide properties and local machine representations of those properties, and ask "Can each machine be made responsible for performing their own localizations for internal bookkeeping purposes?" This would seem to be of particular interest to the type of crowd which would download and use a FreeIPA/sssd solution, but it may not be something they have the time to pursue. :) Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
On Fri, 2014-03-07 at 20:38 +, Nordgren, Bryce L -FS wrote: > > > >>UID/GID solution > > > >>https://fedorahosted.org/sssd/ticket/1715 > > > >> > > > >>Chaining access providers: > > > >>https://fedorahosted.org/sssd/ticket/1326 > > > >I'm not sure these two are enough for a thesis.. > > > > > > I think at least the first one is. > > > You change UID and/or GID on the server. And then you need a > > mechanism > > > to signal to the clients that they need to do cleanup. I was thinking > > > about OpenLMI integration in this case and this sounds like a research > > > topic to me. > > > > I see, this might be an interesting topic. I was initiall only thinking > > about the > > change of the ID itself. > > Something perhaps more worthy of thesis attention may be an examination of > what it would take to start treating UID/GID as a completely internal machine > representation which does not need to be shared. That is, it is important to > have a common set of principal names for users, hosts and services in the > Kerberos store; within an organization, it's important to have common groups > of these principals in an LDAP store; but the importance of having all UIDs > and GIDs be identical seems to be dwindling. > > Authentication via Kerberos doesn't require it. > Authorization using Kerberos principals doesn't require it. > Moving files back and forth with SCP doesn't require it. > An NFSv4 fileserver w/krb5 security doesn't require it. > A CIFS fileserver doesn't require it. > > What still requires that UID/GIDs need to be synchronized? > > (I'm not necessarily asking you all right now. I think it might be a good > thesis question, along with the follow-on: how much work would it take to > migrate off of UID/GID synchronization for good?) Hi Bryce, a very thought provoking question, and it would be very nice if we could, indeed, get rid of Posix IDs, however we can't. One of the reasons is the dreaded 'legacy' applications and protocols. You *could* build a system that can work w/o synchronization, if you carefully restrict what protocols and applications you use (think about distributed filesystems) although you'd still need a local persistent map at least. Backups and restore to other machines would need to be done carefully though, and so on. However there are also issues with operations like 'renames', what happen when you change a user name or a group name ? You do not want to lose access to files when that happen, so you still need a unique identifier that is not the everyday name (or forbid renames). This is not an exhaustive list of course, and every problem can be probably worked around one way or another, however at the moment it is till "easier" to synchronize IDs than not ... HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
> > >>UID/GID solution > > >>https://fedorahosted.org/sssd/ticket/1715 > > >> > > >>Chaining access providers: > > >>https://fedorahosted.org/sssd/ticket/1326 > > >I'm not sure these two are enough for a thesis.. > > > > I think at least the first one is. > > You change UID and/or GID on the server. And then you need a > mechanism > > to signal to the clients that they need to do cleanup. I was thinking > > about OpenLMI integration in this case and this sounds like a research > > topic to me. > > I see, this might be an interesting topic. I was initiall only thinking about > the > change of the ID itself. Something perhaps more worthy of thesis attention may be an examination of what it would take to start treating UID/GID as a completely internal machine representation which does not need to be shared. That is, it is important to have a common set of principal names for users, hosts and services in the Kerberos store; within an organization, it's important to have common groups of these principals in an LDAP store; but the importance of having all UIDs and GIDs be identical seems to be dwindling. Authentication via Kerberos doesn't require it. Authorization using Kerberos principals doesn't require it. Moving files back and forth with SCP doesn't require it. An NFSv4 fileserver w/krb5 security doesn't require it. A CIFS fileserver doesn't require it. What still requires that UID/GIDs need to be synchronized? (I'm not necessarily asking you all right now. I think it might be a good thesis question, along with the follow-on: how much work would it take to migrate off of UID/GID synchronization for good?) Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
On Fri, Mar 07, 2014 at 11:04:45AM -0500, Dmitri Pal wrote: > On 03/07/2014 10:59 AM, Jakub Hrozek wrote: > >On Fri, Mar 07, 2014 at 10:12:43AM -0500, Dmitri Pal wrote: > >>We need to check if those are still relevant > >>* > >>https://thesis-managementsystem.rhcloud.com/topic/show/179/java-loginmodule-using-gssapi > >><- I heard JBoss guys are fixing it > >>* We are talking to Mongo about this: > >>https://thesis-managementsystem.rhcloud.com/topic/show/95/gssapi-auth-plugin-for-mongodb- > >>I would consider pushing it lower in priority > >>* Is this still not implemented: > >>https://thesis-managementsystem.rhcloud.com/topic/show/14/support-the-native-ipa-sudo-schema- > >>? > >This topic is being worked on actively. Me and Pavel have been mentoring > >the student. > > > >>* Is this really needed any more? > >>https://thesis-managementsystem.rhcloud.com/topic/show/13/document-the-internals-of-libldb-and-create-an-example-module-and-example-back-end > >>It looks like Yassir's document covers a lot. > >This topic is about ldb, not SSSD, but I agree it's not terribly important. > > > >>* This > >>https://thesis-managementsystem.rhcloud.com/topic/show/12/implement-support-for-additional-maps-for-the-sssd-fast-cache > >>is still relevant but not a super high priority. > >>* It is unclear whether this is needed any more: > >>https://thesis-managementsystem.rhcloud.com/topic/show/11/implement-3rd-party-id-mapper-in-sssd- > >>seems like people can either use existing mapper (green field case) > >>or already have UID/GID that they need to put into the central > >>server. > >I agree. > > > >>* This one is taken: > >>https://thesis-managementsystem.rhcloud.com/topic/show/10/create-openlmi-provider-for-management-of-the-client-components > >>right? > >This is being worked on by Pavel. > > > >>On SSSD side I used a keyword to try to group all the tickets > >>related to the state/status/health of SSSD. > >>Here is what I got: > >>https://fedorahosted.org/sssd/query?status=assigned&status=new&status=reopened&keywords=~Status&col=id&col=summary&col=keywords&col=status&col=owner&col=type&col=priority&col=milestone&order=priority > >>most in 1.13 so too soon but still there may be some work we can > >>offer. > >> > >> > >>GNOME Keyring work > >>https://fedorahosted.org/sssd/ticket/2221 > >>https://fedorahosted.org/sssd/ticket/ > >These two sounds OK to me, altough they'd require quite a bit of > >mentoring. > > > >>UID/GID solution > >>https://fedorahosted.org/sssd/ticket/1715 > >> > >>Chaining access providers: > >>https://fedorahosted.org/sssd/ticket/1326 > >I'm not sure these two are enough for a thesis.. > > I think at least the first one is. > You change UID and/or GID on the server. And then you need a > mechanism to signal to the clients that they need to do cleanup. I > was thinking about OpenLMI integration in this case and this sounds > like a research topic to me. I see, this might be an interesting topic. I was initiall only thinking about the change of the ID itself. > > > > >>One can dig more into 14-15 releases to see if there is anything > >>else worth looking into. > >What about the validator in ding-libs? > > I am planning to do some prototyping and publish a design, would it > rain the parade? Ah, I remember you said something along these lines yesterday on our meeting. In that case it makes little sense to add the validation as a topic. > > > > >What about developing a set of tests using cwrap? > > +1 I filed https://fedorahosted.org/sssd/ticket/2277 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
On Fri, 07 Mar 2014, Dmitri Pal wrote: On 03/06/2014 10:55 AM, Petr Spacek wrote: On 6.3.2014 14:32, Petr Spacek wrote: now it is the right time to propose topics for theses in the next university year. I propose "[RFE] IPA should support and manage DNS sites" https://fedorahosted.org/freeipa/ticket/2008 It is rotting in the backlog and we are not going to touch it any time soon. There is very low amount of 'theory' behind it but IMHO it is complex enough: - Some theoretical analysis of our proposal sounds like a good idea. We don't know if it is the best way or not. - Some testing with various *real* non-SSSD clients will be helpful. - Analysis how this can work with DNSSEC will be helpful. - This feature needs API/CLI/UI design. It is not clear how the workflow should look like etc. - Support for roaming clients (in bind-dyndb-ldap) is missing. The scope can be changed as necessary. We need to check if those are still relevant * https://thesis-managementsystem.rhcloud.com/topic/show/179/java-loginmodule-using-gssapi <- I heard JBoss guys are fixing it * We are talking to Mongo about this: https://thesis-managementsystem.rhcloud.com/topic/show/95/gssapi-auth-plugin-for-mongodb- I would consider pushing it lower in priority There is already SASL support in MongoDB, though existing SASL GSSAPI authentication is only available in MongoDB Enterprise. http://docs.mongodb.org/manual/tutorial/control-access-to-mongodb-with-kerberos-authentication/ -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
On 03/07/2014 10:59 AM, Jakub Hrozek wrote: On Fri, Mar 07, 2014 at 10:12:43AM -0500, Dmitri Pal wrote: We need to check if those are still relevant * https://thesis-managementsystem.rhcloud.com/topic/show/179/java-loginmodule-using-gssapi <- I heard JBoss guys are fixing it * We are talking to Mongo about this: https://thesis-managementsystem.rhcloud.com/topic/show/95/gssapi-auth-plugin-for-mongodb- I would consider pushing it lower in priority * Is this still not implemented: https://thesis-managementsystem.rhcloud.com/topic/show/14/support-the-native-ipa-sudo-schema- ? This topic is being worked on actively. Me and Pavel have been mentoring the student. * Is this really needed any more? https://thesis-managementsystem.rhcloud.com/topic/show/13/document-the-internals-of-libldb-and-create-an-example-module-and-example-back-end It looks like Yassir's document covers a lot. This topic is about ldb, not SSSD, but I agree it's not terribly important. * This https://thesis-managementsystem.rhcloud.com/topic/show/12/implement-support-for-additional-maps-for-the-sssd-fast-cache is still relevant but not a super high priority. * It is unclear whether this is needed any more: https://thesis-managementsystem.rhcloud.com/topic/show/11/implement-3rd-party-id-mapper-in-sssd- seems like people can either use existing mapper (green field case) or already have UID/GID that they need to put into the central server. I agree. * This one is taken: https://thesis-managementsystem.rhcloud.com/topic/show/10/create-openlmi-provider-for-management-of-the-client-components right? This is being worked on by Pavel. On SSSD side I used a keyword to try to group all the tickets related to the state/status/health of SSSD. Here is what I got: https://fedorahosted.org/sssd/query?status=assigned&status=new&status=reopened&keywords=~Status&col=id&col=summary&col=keywords&col=status&col=owner&col=type&col=priority&col=milestone&order=priority most in 1.13 so too soon but still there may be some work we can offer. GNOME Keyring work https://fedorahosted.org/sssd/ticket/2221 https://fedorahosted.org/sssd/ticket/ These two sounds OK to me, altough they'd require quite a bit of mentoring. UID/GID solution https://fedorahosted.org/sssd/ticket/1715 Chaining access providers: https://fedorahosted.org/sssd/ticket/1326 I'm not sure these two are enough for a thesis.. I think at least the first one is. You change UID and/or GID on the server. And then you need a mechanism to signal to the clients that they need to do cleanup. I was thinking about OpenLMI integration in this case and this sounds like a research topic to me. One can dig more into 14-15 releases to see if there is anything else worth looking into. What about the validator in ding-libs? I am planning to do some prototyping and publish a design, would it rain the parade? What about developing a set of tests using cwrap? +1 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
On Fri, Mar 07, 2014 at 10:12:43AM -0500, Dmitri Pal wrote: > We need to check if those are still relevant > * > https://thesis-managementsystem.rhcloud.com/topic/show/179/java-loginmodule-using-gssapi > <- I heard JBoss guys are fixing it > * We are talking to Mongo about this: > https://thesis-managementsystem.rhcloud.com/topic/show/95/gssapi-auth-plugin-for-mongodb- > I would consider pushing it lower in priority > * Is this still not implemented: > https://thesis-managementsystem.rhcloud.com/topic/show/14/support-the-native-ipa-sudo-schema- > ? This topic is being worked on actively. Me and Pavel have been mentoring the student. > * Is this really needed any more? > https://thesis-managementsystem.rhcloud.com/topic/show/13/document-the-internals-of-libldb-and-create-an-example-module-and-example-back-end > It looks like Yassir's document covers a lot. This topic is about ldb, not SSSD, but I agree it's not terribly important. > * This > https://thesis-managementsystem.rhcloud.com/topic/show/12/implement-support-for-additional-maps-for-the-sssd-fast-cache > is still relevant but not a super high priority. > * It is unclear whether this is needed any more: > https://thesis-managementsystem.rhcloud.com/topic/show/11/implement-3rd-party-id-mapper-in-sssd- > seems like people can either use existing mapper (green field case) > or already have UID/GID that they need to put into the central > server. I agree. > * This one is taken: > https://thesis-managementsystem.rhcloud.com/topic/show/10/create-openlmi-provider-for-management-of-the-client-components > right? This is being worked on by Pavel. > > On SSSD side I used a keyword to try to group all the tickets > related to the state/status/health of SSSD. > Here is what I got: > https://fedorahosted.org/sssd/query?status=assigned&status=new&status=reopened&keywords=~Status&col=id&col=summary&col=keywords&col=status&col=owner&col=type&col=priority&col=milestone&order=priority > most in 1.13 so too soon but still there may be some work we can > offer. > > > GNOME Keyring work > https://fedorahosted.org/sssd/ticket/2221 > https://fedorahosted.org/sssd/ticket/ These two sounds OK to me, altough they'd require quite a bit of mentoring. > > UID/GID solution > https://fedorahosted.org/sssd/ticket/1715 > > Chaining access providers: > https://fedorahosted.org/sssd/ticket/1326 I'm not sure these two are enough for a thesis.. > > One can dig more into 14-15 releases to see if there is anything > else worth looking into. What about the validator in ding-libs? What about developing a set of tests using cwrap? ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
On 03/06/2014 10:55 AM, Petr Spacek wrote: On 6.3.2014 14:32, Petr Spacek wrote: now it is the right time to propose topics for theses in the next university year. I propose "[RFE] IPA should support and manage DNS sites" https://fedorahosted.org/freeipa/ticket/2008 It is rotting in the backlog and we are not going to touch it any time soon. There is very low amount of 'theory' behind it but IMHO it is complex enough: - Some theoretical analysis of our proposal sounds like a good idea. We don't know if it is the best way or not. - Some testing with various *real* non-SSSD clients will be helpful. - Analysis how this can work with DNSSEC will be helpful. - This feature needs API/CLI/UI design. It is not clear how the workflow should look like etc. - Support for roaming clients (in bind-dyndb-ldap) is missing. The scope can be changed as necessary. We need to check if those are still relevant * https://thesis-managementsystem.rhcloud.com/topic/show/179/java-loginmodule-using-gssapi <- I heard JBoss guys are fixing it * We are talking to Mongo about this: https://thesis-managementsystem.rhcloud.com/topic/show/95/gssapi-auth-plugin-for-mongodb- I would consider pushing it lower in priority * Is this still not implemented: https://thesis-managementsystem.rhcloud.com/topic/show/14/support-the-native-ipa-sudo-schema- ? * Is this really needed any more? https://thesis-managementsystem.rhcloud.com/topic/show/13/document-the-internals-of-libldb-and-create-an-example-module-and-example-back-end It looks like Yassir's document covers a lot. * This https://thesis-managementsystem.rhcloud.com/topic/show/12/implement-support-for-additional-maps-for-the-sssd-fast-cache is still relevant but not a super high priority. * It is unclear whether this is needed any more: https://thesis-managementsystem.rhcloud.com/topic/show/11/implement-3rd-party-id-mapper-in-sssd- seems like people can either use existing mapper (green field case) or already have UID/GID that they need to put into the central server. * This one is taken: https://thesis-managementsystem.rhcloud.com/topic/show/10/create-openlmi-provider-for-management-of-the-client-components right? * https://thesis-managementsystem.rhcloud.com/topic/show/7/central-management-of-automount-locations-in-freeipa - does not seem like something worth time * This one would be really nice: https://thesis-managementsystem.rhcloud.com/topic/show/6/reporting-capability-in-freeipa * And this one would be nice too: https://thesis-managementsystem.rhcloud.com/topic/show/5/time-based-account-policies-in-freeipa Here are couple more IPA ones that came to mind: https://fedorahosted.org/freeipa/ticket/4008 https://fedorahosted.org/freeipa/ticket/3656 https://fedorahosted.org/freeipa/ticket/4062 https://fedorahosted.org/freeipa/ticket/1225 <- came up 3 times during this week (registering external certs, uploading XML token files etc.) May be it is a special IPA command like: ipa upload-and-run that would use scp to copy file to the server and then call a command on the server side using this file. Details need to be worked out. On SSSD side I used a keyword to try to group all the tickets related to the state/status/health of SSSD. Here is what I got: https://fedorahosted.org/sssd/query?status=assigned&status=new&status=reopened&keywords=~Status&col=id&col=summary&col=keywords&col=status&col=owner&col=type&col=priority&col=milestone&order=priority most in 1.13 so too soon but still there may be some work we can offer. GNOME Keyring work https://fedorahosted.org/sssd/ticket/2221 https://fedorahosted.org/sssd/ticket/ UID/GID solution https://fedorahosted.org/sssd/ticket/1715 Chaining access providers: https://fedorahosted.org/sssd/ticket/1326 One can dig more into 14-15 releases to see if there is anything else worth looking into. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Propose FreeIPA theses: IPA support for sites
On 6.3.2014 14:32, Petr Spacek wrote: now it is the right time to propose topics for theses in the next university year. I propose "[RFE] IPA should support and manage DNS sites" https://fedorahosted.org/freeipa/ticket/2008 It is rotting in the backlog and we are not going to touch it any time soon. There is very low amount of 'theory' behind it but IMHO it is complex enough: - Some theoretical analysis of our proposal sounds like a good idea. We don't know if it is the best way or not. - Some testing with various *real* non-SSSD clients will be helpful. - Analysis how this can work with DNSSEC will be helpful. - This feature needs API/CLI/UI design. It is not clear how the workflow should look like etc. - Support for roaming clients (in bind-dyndb-ldap) is missing. The scope can be changed as necessary. -- Petr^2 Spacek ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
