On Mon, Apr 27, 2015 at 06:41:42PM +0300, Alexander Bokovoy wrote: > On Mon, 27 Apr 2015, Simo Sorce wrote: > >On Mon, 2015-04-27 at 15:04 +0300, Alexander Bokovoy wrote: > >>On Mon, 27 Apr 2015, Jakub Hrozek wrote: > >>>On Sun, Apr 26, 2015 at 06:17:21PM -0400, Simo Sorce wrote: > >>>> Very nice writeup! > >>>> A few comments.. > >>>> > >>>> On Sun, 2015-04-26 at 21:22 +0200, Jakub Hrozek wrote: > >>>> > Hi, > >>>> > > >>>> > I prepared design page for the one-way trusts feature: > >>>> > https://fedorahosted.org/sssd/wiki/DesignDocs/OneWayTrusts > >>>> > > >>>> > The text is copied below as well for your convenience. I have a couple > >>>> > of questions to discuss: > >>>> > - Is it worth it to put the keytabs into a new subdirectory so that > >>>> > a special SELinux label can be applied? I think yes, since then > >>>> > we'd have additional layer of protection of the trust secrets > >>>> > >>>> It is not clear to me what would be the advantage, who are you trying to > >>>> protect against ? > >>>> Adding different labels makes sense only if sssd_be has a different > >>>> label from the other sssd processes, but then you can simply have > >>>> selinux policies that label accordingly to the parent process in the > >>>> same directory, no? > >>> > >>>Yes, I tried to future-proof the directory structure against different > >>>sssd processes that need access to the database (responders) but not the > >>>keytabs, because I suspect we won't think about the directory structure > >>>again once we set it up :-). And a single separate directory just seemed > >>>easier to label with a new context than several files. > >>> > >>>In the end, I don't care that much as long as the keytabs have different > >>>contexts that the responders can't access. > >>Given that we want to have one keytab per forest trust and naming > >>keytabs after forest trust name, we can live with a single directory. It > >>would be good, indeed, to have it separated from the rest of sssd. > >> > >> > >>>> > >>>> > - Is there any reasonable fallback beyond re-fetching the keytab we > >>>> > can do? I can't think of any.. > >>>> > >>>> Be careful with refetches and so we do not want to end up in infinite > >>>> loops, where the keytab can be fetched but still operation fails for > >>>> whatever reason. > >>> > >>>Sure, I will add a more explicit note once we agree what the mechanism > >>>would be. > >>Another thing to remember is a potential need to limit enctypes you'd be > >>requesting because camellia ciphers are not know to AD and might cause > >>issues at some point. > > > >SSSD should not be in the business of *creating* keytabs, it should only > >be allowed to retrieve a precreated key, so SSSD shouldn't care about > >enctypes, it will get only those that the FreeIPA code stored in the key > >in LDAP. > So this means ipasam needs to limit enctypes when asking for the keys. > > > >>>> One thing that should be checked is if the new keytab and old keytab > >>>> have the same keys in them, and, if so just stop re-fetching and raising > >>>> a fatal error (at list for a reasonable period of time). > >>> > >>>I thought about a flag in the ipa_ad_server_ctx structure, because after > >>>the trust is deleted and set up again, the kvno is still 1. When you say > >>>'keys', are you proposing to compare the secret key? > >>>(krb5_keytab_entry.key) > >>Yes, don't use KVNO value to compare, verify actual keys. > > > >It would be nice to avoid the need to link directly to krb5 calls, but > >it is probably safer to check by key value.
About linking to the krb5 calls, I don't think there would be the same concerns as we had with krb5_child for instance. Because this is a private sssd keytab, we can make it accessible to the sssd user and all krb5 calls can run as this user. > Note that we are dealing with a key material from a separate realm and > we create the key in IPA LDAP by means of ipasam which results in the > fact there is no way to co-relate KVNO between the key in IPA LDAP and in AD > LDAP other than by authenticating or comparing key value to the local > copy. > > On the other hand, when trust is re-established, we actually remove it > completely and re-create the objects. This means for new trust KVNO will > always be 1 and will only increase if there was a TDO password change > operation initiated by AD side (which currently doesn't work, we have > this part broken). So I think we probably need to remember a timestamp > of when trust object -- not the Kerberos principal but the trust object > that ipasam maintains for Samba -- was created/modified and compare that > with the time we requested keytab before as a short circuit. As we run > on the same server as LDAP server, that time should be comparable. Is this data available in krbLastPwdChange ? It's certainly doable to store that time in sysdb. But since the result of the operation is the keytab, it seems more natural to me to compare keytab contents and not a separate (even if logically related) object. > > >>>> > - Should the IPA tools signal SSSD either via UNIX signals or via > >>>> > the DBus API once a trust has been added or removed to minimize > >>>> > the race condition and improve user experience? Currently I hope > >>>> > not, the proposed mechanism should be enough but testing is still > >>>> > required. > >>>> > > >>>> > When the design page is agreed on, I'll turn the three subsections of > >>>> > the implementation phase into smaller tickets and close the tracker. > >>>> > > >>>> > = Feature Name = > >>>> > > >>>> > Related ticket(s): > >>>> > * https://fedorahosted.org/sssd/ticket/2579 > >>>> > > >>>> > === Problem statement === > >>>> > The next IPA release will support one-way trusts. SSSD needs to add > >>>> > support > >>>> > for this feature in its server mode. > >>>> > > >>>> > === Use cases === > >>>> > One-way trust to Active Directory where FreeIPA realm trusts Active > >>>> > Directory > >>>> > forest using cross-forest trust feature of AD but the AD forest does > >>>> > not trust > >>>> > FreeIPA realm. Users from AD forest can access resources in FreeIPA > >>>> > realm. > >>>> > > >>>> > === Overview of the solution === > >>>> > At a high level, SSSD needs to examine the trust objects whether they > >>>> > are one-way or two way trusts. For each one-way trust, SSSD needs to > >>>> > fetch > >>>> > and store the keytab and use the keytab to secure the connection. For > >>>> > two-way trusts, we can keep using the existing code that reuses the IPA > >>>> > realm and the system keytab for both IPA and AD connectins. Care must > >>>> > be > >>>> > taken to remove keytabs of trusts that were removed as well. > >>>> > > >>>> > Fetching the keytab would be done by calling the `ipa-getkeytab` > >>>> > utility > >>>> > for every one-way trust. The keytab would only be (re)fetched if it's > >>>> > missing or if attempting to use the keytab failed. On the IPA server, > >>>> > we must make sure that the IPA server identity is allowed to read the > >>>> > keytab. > >>>> > > >>>> > Because handling multiple keytabs increases the risk of failing > >>>> > connections in > >>>> > case the trust wasn't setup correctly, we need to modify the failover > >>>> > code to > >>>> > not set the whole back end offline in case connecting to a subdomain > >>>> > AD server > >>>> > fails. Instead, the subdomain will be marked as inactive for a short > >>>> > period of > >>>> > time, during which it would act as offline. The proper way of solving > >>>> > this > >>>> > problem would be to rework the failover module so that it can act per > >>>> > domain, > >>>> > not only per back end, however, that change is out of scope for this > >>>> > release. > >>>> > > >>>> > === Implementation details === > >>>> > This section describes all the required changes in detail. > >>>> > > >>>> > ==== Reading the subdomains in the IPA subdomain handler ==== > >>>> > The IPA subdomain handler will include the attribute > >>>> > `ipaNTTrustDirection` > >>>> > when reading the trust objects. Currently this attribute is not > >>>> > readable > >>>> > by the host principal, so the IPA ACIs must be relaxed (ipa ticket?). > >>>> > If > >>>> > the trust direction is set to an OR of > >>>> > `lsa.LSA_TRUST_DIRECTION_OUTBOUND` > >>>> > and `lsa.LSA_TRUST_DIRECTION_INBOUND`, then it's a two-way trust and > >>>> > we'll > >>>> > just use the existing code that re-uses the IPA keytab for the AD > >>>> > trusted > >>>> > domain as well. If the attribute is only > >>>> > `lsa.LSA_TRUST_DIRECTION_OUTBOUND`, > >>>> > we handle the trust as a one-way trust. The trust type can be stored in > >>>> > `ipa_ad_server_ctx`. > >>>> > >>>> What do you do if you have only lsa.LSA_TRUST_DIRECTION_INBOUND ? > >>> > >>>Log this object loudly and ignore. Is there another reasonable thing to > >>>do other than skip such trust relationship ? (Yes, skipping the object > >>>should be spelled out explicitly in the design page) > >>Yes, nothing else you can do. I'm not sure at which point we'll get to > >>INBOUND-only case. > > > >We should probably just ignore w/o even screaming too loud. > Yep. OK, fine. > > > > >>>> > Each `sss_domain_info` structure will be created as `inactive` in the > >>>> > subdomain code. After enumerating the trusted domains, the subdomain > >>>> > handler will check if a keytab already exists for every one-way trusted > >>>> > domain. If yes, the domain is ready to use and can be enabled. If > >>>> > there is > >>>> > no keytab, the subdomain handler will fork out a call to > >>>> > `ipa-getkeytab`, > >>>> > fetch the keytab and store it under `/var/lib/sss/db`. The > >>>> > `ipa-getkeytab` > >>>> > call will be done using Kerberos credentials the host has. IPA ACIs > >>>> > must > >>>> > be modified accordingly to allow the IPA server principals to fetch the > >>>> > trust keytabs, but noone else. > >>>> > > >>>> > The directory `/var/lib/sss/db` is already only accessible to the sssd > >>>> > user only. As an additional security measure, we might want to store > >>>> > the > >>>> > keytabs under a new directory so that the keytabs also receive a > >>>> > SELinux > >>>> > context stricter than the default `sssd_var_lib_t`. If fetching the > >>>> > keytab > >>>> > succeeds, the domain would be enabled. The SELinux policy must also be > >>>> > adjusted to allow calling `ipa-getkeytab` by the `sssd_be` process. > >>>> > >>>> Getting a keytab is an LDAP extended operation, do you want to fork off > >>>> ipa-getkeytab to avoid coding the LDAP operatin in SSSD ? Or for some > >>>> other reason ? > >>> > >>>No, I just wanted to use code that is already there. Retrieving the > >>>keytab should be rare enough to justify the overhead of forking an > >>>executable and would let us to keep up with any changes IPA might do. > >>> > >>>Or let me turn that question around -- do you see any advantage of > >>>searching the keytab directly from SSSD? > >>I can see a downside in the fact that you'd need to handle ASN.1 > >>encoding/decoding to fetch the keytab and if we ever change its > >>structure, SSSD would be another point of failure. Calling out to > >>ipa-getkeytab is giving us assurance to keep things working. > > > >We cannot change the format, if we do we'll have to indtroduce a new > >version and support the old one. So this is not a problem. > > > >The advantage of doing this directly is if we decide (for whatever > >reason) to store the key material directly in the ldb cache instead of a > >file. If we did that then we could use a MEMORY keytab for the various > >operations by fetching it out of the cache and it would not ever hit the > >filesystem. Hoewever we may not want to have that key material in LDB at > >all, it is just a possibility. > Right, it is currently easier to call out and leave ipa-getkeytab to do > the job because we are practically running on IPA master in this more. I agree. > > > >>>> > If any trust relationships were removed, the corresponding keytabs must > >>>> > be removed from the disk as well. > >>>> > >>>> How do you do this ? > >>>> Just regularly enumerate the keytab files on disk and remove the ones > >>>> that have no object in the cache ? > >>> > >>>Yes, after the subdomain handler finishes. We alrady have a return boolean > >>>'refresh_has_changes' and re-initialize domain-realm mapping for > >>>example. > >>> > >>>> One advantage of using a separate subdir for keytabs, as you propose, > >>>> would be to wipe it clean every time sssd restart (at stop and at start > >>>> too for good measure), then enumerate the trusts on the server and > >>>> re-fetch any keytab. > >>> > >>>I thought about this, but it seemed a bit wasteful. But now that I think > >>>of it, this would present a 'known control point' to start fresh..so it > >>>might come handy. > >>If you do so, please make it triggered via some explicit mechanism, not > >>as a default. > > > >Why not do it at restart ? > Do you want to always re-retrive the keys? I was under assumption we are > not going to do that. From my point of view, the pro is the ability for admin to refresh the trust keytabs by simply restarting the sssd service. The con is the traffic towards IPA and the overhead of fetching and storing the keytabs, but I think normally sssd restarts on the servers should be quite rare -- so I would prefer to implement the fetching on restart at this point. (snipped the rest) _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel