Re: [Freeipa-devel] DNS improvements: Should we add some sanity checking?
On 09/13/2013 06:17 PM, Simo Sorce wrote: On Fri, 2013-09-13 at 09:29 +0200, Petr Spacek wrote: Hello list, Jan Pazdziora jpazdzi...@redhat.com proposed that 'ipa dns*' commands should do some sanity checking/waiting after the record is added to LDAP. I think that it could be valuable and I would like to get opinions from freeipa-devel list. === The problem === ipa dnsrecord-add and similar commands add the data to LDAP, but it doesn't mean that the data are *immediately* resolvable via DNS protocol. Note that data from LDAP are *asynchronously* read and processed by Named and the time when records are available is not predictable. A mismatch between LDAP can be caused by some connection problem between DNS and LDAP servers, LDAP or DNS server restart, or simply by a bug in DNS-LDAP synchronization code. (This is becomming more and more important if we consider the whole DNSSEC effort and related re-factoring.) My experience is that users are very confused if the ipa dnsrecord-add command says 'record added' but it is still not available via DNS. It is really hard to debug when you see the problem first 10 times :-) === The proposal === 1. Let FreeIPA framework to change DNS data in LDAP as we do now. 2. After each change, do DNS queries for changed record and wait until the new data are available. IMHO it is very cheap operation (in usual cases 1 DNS packet back and forth) and it would save a lot of headaches to users and support. This will naturally catch the case where named crashes after the change etc. === Expected outcome === There will not be any failure like this: $ ipa-adtrust-install $ ipa dnszone-add $AD_DOMAIN --name-server=advm.$AD_DOMAIN --admin-email=hostmaster@$AD_DOMAIN.com --force --forwarder=$AD_IP --forward-policy=only --ip-address=$AD_IP Zone name: dom123.example.com [...] $ ipa trust-add --type=ad DOM123.EXAMPLE.COM --admin Administrator --password Password for ad...@dom123.example.com: ipa: ERROR: Cannot find specified domain or server name Would it make sense to change the code to use dynDNS update to add records ? Wouldn't that force named to be in sync ? Simo. Switching from LDAP modify operation to dynDNS update seems as a too big change to me. If nothing else, it would not fly with our LDAP ACI/permission system and ability to delegate DNS read/write rights to somebody else. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Add delegation info to MS-PAC
On 09/13/2013 03:01 PM, Alexander Bokovoy wrote: On Thu, 07 Feb 2013, Simo Sorce wrote: This information is not strictly required but is part of the MS-PAC specification and I had some time to kill on the plane on my last trip back. I tested it briefly with cross-realm trusts and it seem to work fine. Neither IPA nor AD2012 complained when looking at PACs, do far. Reviving. It is actually required part as without it smbd will deny our attempt to establish local part of the trust in some cases by misinterpreting what we put in the PAC and thinking that a service impersonating original user is the actual user but taking original user name as an account name. With this patch everything works fine. ACK. Is this fix required also for FreeIPA 3.3 and it's features? I did not understand that from the bug description. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 451-458 Web UI devel and source code documentation
On 09/13/2013 08:31 PM, Dmitri Pal wrote: On 09/13/2013 09:12 AM, Simo Sorce wrote: On Fri, 2013-09-13 at 13:54 +0200, Petr Vobornik wrote: ... Well my concern remains that if we want to change later it will take some effort, but I guess it is better to have improved docs now and take care of the 'ruby' problem later if it becomes an issue. I find it amusing we have to use ruby to document javascript though, you would think javascript is a good enough language to do that :-D Simo. I take this as an ack for JSDuck. Right. Until we find that using ruby is indeed a blocker or until we find some way to get rid of ruby without degrading Web UI docs quality... Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Add delegation info to MS-PAC
On Mon, 16 Sep 2013, Martin Kosek wrote: On 09/13/2013 03:01 PM, Alexander Bokovoy wrote: On Thu, 07 Feb 2013, Simo Sorce wrote: This information is not strictly required but is part of the MS-PAC specification and I had some time to kill on the plane on my last trip back. I tested it briefly with cross-realm trusts and it seem to work fine. Neither IPA nor AD2012 complained when looking at PACs, do far. Reviving. It is actually required part as without it smbd will deny our attempt to establish local part of the trust in some cases by misinterpreting what we put in the PAC and thinking that a service impersonating original user is the actual user but taking original user name as an account name. With this patch everything works fine. ACK. Is this fix required also for FreeIPA 3.3 and it's features? I did not understand that from the bug description. Yes. It is one of fixes to the issues Tomas was seeing with his test automation scripts. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI
On 09/13/2013 08:39 PM, Dmitri Pal wrote: On 09/13/2013 11:55 AM, Petr Vobornik wrote: On 09/05/2013 06:25 AM, Nathaniel McCallum wrote: This patch has a few problems that I'd like some help with. There are a few notes here as well. snip Some additional findings: 1. Inconsistency: 'ipatokenowner' in command output should be normalized the same way as 'manager' in user plugin or 'seealso' in selinuxusermap. See _normalize_manager and _convert_manager methods. Question for all: Why don't we have general methods for such task? RFE? +1. https://fedorahosted.org/freeipa/ticket/3932 Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Improve FreeIPA usability in cloud environments
On 15.9.2013 20:19, Dmitri Pal wrote: On 09/14/2013 01:27 PM, Simo Sorce wrote: On Fri, 2013-09-13 at 14:26 -0400, Dmitri Pal wrote: On 09/13/2013 09:08 AM, Simo Sorce wrote: On Fri, 2013-09-13 at 10:26 +0200, Petr Spacek wrote: Hello list, FreeIPA deployments in cloud environments do not work very well because 'clouds' break some assumptions we made during FreeIPA's design. We should fix it somehow:-) === Problems === - A machine has two host names in DNS: -- The first name is internal to the cloud and resolvable only from inside of the cloud. --- This name should be used for communication inside cloud. --- E.g. 'ipa.cust1.cloud.' --- Internal name is mapped to internal IP address, see below. -- The second name is external to the cloud and should be used for communication between the Internet and cloud. --- E.g. 'ipa.example.com.' --- External name maps to external IP address, see below. - A machine has two IP addresses: -- Internal, private IP address configured at the machine's interface --- Typically the only IP address known to the machine. --- E.g. 192.0.2.22 --- IP address can change dynamically, at least after a machine reboot. -- External, public IP address: --- Typically mapped to internal address at cloud boundary (NAT). --- E.g. 203.0.113.113 --- IP address can change dynamically, at least after a machine reboot. Related tickets: https://fedorahosted.org/freeipa/ticket/2648 https://fedorahosted.org/freeipa/ticket/2715 The natural request is to add support for DNS views/split horizon DNS into FreeIPA, so different names and IP addresses can be served to clients inside and outside of the cloud. Is it enough? What else should we change to make FreeIPA reliable in clouds? I do not understand what's the use of views in this case. Views are used when you want to assign different IP addresses to the same name depending on where the query comes from. You are right, the scenario described by me doesn't require views. Please see reply from James in another part of this thread - his setup has shared host name (internal = external) but different IP addresses for internal and external usage. The question is if DNS is the right layer to solve the problem. Some oddities like this could be solved on IP routing level: I.e. use 'external'/public IP address everywhere and route packets with this 'external IP' to the right part of the internal network. Solution on routing layer can be technically feasible, but it doesn't mean that it is politically acceptable. People usually don't want to touch routing unless absolutely necessary :-) -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNS improvements: Should we add some sanity checking?
On 16.9.2013 09:06, Martin Kosek wrote: On 09/13/2013 06:17 PM, Simo Sorce wrote: On Fri, 2013-09-13 at 09:29 +0200, Petr Spacek wrote: Hello list, Jan Pazdziora jpazdzi...@redhat.com proposed that 'ipa dns*' commands should do some sanity checking/waiting after the record is added to LDAP. I think that it could be valuable and I would like to get opinions from freeipa-devel list. === The problem === ipa dnsrecord-add and similar commands add the data to LDAP, but it doesn't mean that the data are *immediately* resolvable via DNS protocol. Note that data from LDAP are *asynchronously* read and processed by Named and the time when records are available is not predictable. A mismatch between LDAP can be caused by some connection problem between DNS and LDAP servers, LDAP or DNS server restart, or simply by a bug in DNS-LDAP synchronization code. (This is becomming more and more important if we consider the whole DNSSEC effort and related re-factoring.) My experience is that users are very confused if the ipa dnsrecord-add command says 'record added' but it is still not available via DNS. It is really hard to debug when you see the problem first 10 times :-) === The proposal === 1. Let FreeIPA framework to change DNS data in LDAP as we do now. 2. After each change, do DNS queries for changed record and wait until the new data are available. IMHO it is very cheap operation (in usual cases 1 DNS packet back and forth) and it would save a lot of headaches to users and support. This will naturally catch the case where named crashes after the change etc. === Expected outcome === There will not be any failure like this: $ ipa-adtrust-install $ ipa dnszone-add $AD_DOMAIN --name-server=advm.$AD_DOMAIN --admin-email=hostmaster@$AD_DOMAIN.com --force --forwarder=$AD_IP --forward-policy=only --ip-address=$AD_IP Zone name: dom123.example.com [...] $ ipa trust-add --type=ad DOM123.EXAMPLE.COM --admin Administrator --password Password for ad...@dom123.example.com: ipa: ERROR: Cannot find specified domain or server name Would it make sense to change the code to use dynDNS update to add records ? Wouldn't that force named to be in sync ? Simo. Switching from LDAP modify operation to dynDNS update seems as a too big change to me. If nothing else, it would not fly with our LDAP ACI/permission system and ability to delegate DNS read/write rights to somebody else. I can see pros and cons for both ways: LDAP: + we have the code :-) + ACI magic - works only with bind-dyndb-ldap - can get out of sync (bugs, timeouts etc.) Standard DNS updates: + can work with any DNS server + with AD integration, we could use existing AD DNS infrastructure: i.e. manage DNS records for FreeIPA servers and host without deploying a new DNS server and related 'politics' + bind-dyndb-ldap is not necessary (ouh, my work is useless now :-)) - we don't have the code in FreeIPA framework - ACI magic is not available (in reality, it depends on the DNS server) - reading of current state could be more complex for user interface (On the other hand, current user interface doesn't show real state of thing because LDAP != DNS.) -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Add delegation info to MS-PAC
On 09/16/2013 09:14 AM, Alexander Bokovoy wrote: On Mon, 16 Sep 2013, Martin Kosek wrote: On 09/13/2013 03:01 PM, Alexander Bokovoy wrote: On Thu, 07 Feb 2013, Simo Sorce wrote: This information is not strictly required but is part of the MS-PAC specification and I had some time to kill on the plane on my last trip back. I tested it briefly with cross-realm trusts and it seem to work fine. Neither IPA nor AD2012 complained when looking at PACs, do far. Reviving. It is actually required part as without it smbd will deny our attempt to establish local part of the trust in some cases by misinterpreting what we put in the PAC and thinking that a service impersonating original user is the actual user but taking original user name as an account name. With this patch everything works fine. ACK. Is this fix required also for FreeIPA 3.3 and it's features? I did not understand that from the bug description. Yes. It is one of fixes to the issues Tomas was seeing with his test automation scripts. I've also pushed it to ipa-3-3: 7de103739172e4d3690d71fb686addc4edae027e -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Coverity fixes for slapi-nis
On 2.9.2013 15:58, Alexander Bokovoy wrote: Hi Nalin, attached please find two patches that fix minor Coverity issues. The first patch is for issue 11937 which is a false positive but caught up wrong use of the helper method -- the method map_data_set_entry() passes key and value length arguments through to map_data_save_list() which expects them to be arrays but we pass pointer to the variable. Luckily, in our case map_data_save_list() never goes beyond element 0 of the array so the fix is mostly cosmetic. The second fix is in PAM wrapper in the tests and minor too -- we would leak a memory if PAM wrapper wasn't called under wrapping condition. The same patches are in my Fedora people slapi-nis tree, branch 'coverity': http://fedorapeople.org/cgit/abbra/public_git/slapi-nis.git/log/?h=coverity ACK -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0063 Do not show unexpected error in ipa-ldap-updater
On 09/03/2013 12:48 PM, Ana Krivokapic wrote: Hello, This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3825. ACK, pushed to master: 15cc9740c0ae7d4715df97a1b9ec0166d47c30c2 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0065 Follow tmpfiles.d packaging guidelines
On 09/04/2013 06:27 PM, Ana Krivokapic wrote: Hello, This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3881. Thank you! ACK, pushed to: master: 7c22b852c73b94148043dd35636e2dd21a80d531 ipa-3-3: 771511fd2597c907fc5293ce1289070551240a91 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 450 Fix redirection on deletion of last dns record entry
On 09/06/2013 04:47 PM, Ana Krivokapic wrote: On 09/06/2013 02:30 PM, Petr Vobornik wrote: https://fedorahosted.org/freeipa/ticket/3907 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK Pushed to: master: 5c4a72de59840b84a128c8649c8d7b444993 ipa-3-3: ac5447f57953dd022f63f9f801c5628df3e4b832 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0094-0099 Make Fuzzy objects available for the whole ipatests module
Petr Viktorin wrote:
On 09/13/2013 07:04 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
On 09/13/2013 04:12 PM, Tomas Babej wrote:
Hi,
The following patches move and extend the functionality of Fuzzy
objects. This is necessary to use them from within integration tests.
-1 to the idea.
I'm not a fan of the Fuzzy objects; they basically exist so that you can
use regex matching in the Declarative tests.
As you've probably noticed Fuzzy is quite specific to the framework and
its test suite -- see the strict bytes/unicode separation and the amount
of changes it takes to tear them out.
I'm also not a fan of having a generic Match anything using some rules
object where everybody adds behavior specific to their use case. Each
addition increases the complexity and number of corner cases, and the
complete intended functionality can never be achieved.
Using regular expressions directly should actually be easier and less
error-prone in most cases.
If you disagree, I'd like to see your use case.
I'm not sure what the objection is, Fuzzy is just an abstraction. It
lets one do in-line regex which is the reason it was introduced
(initially for uid and gid because they are non-deterministic).
Yes. In-line is the key here. It lets you do regex matching via the ==
operator, which is what Declarative tests need, but elsewhere the
abstraction is completely unnecessary.
Replacing it would either a) replicate its functionality almost
completely or b) spread duplicate regex code all over the place.
I'd go for b; spreading this code:
import re
some_regex = re.compile('some.*regex$')
...
assert some_regex.search(x)
instead of:
from wherever import Fuzzy
warm_fuzzy = Fuzzy('some.*regex$')
...
assert x == warm_fuzzy
all over the place is fine in my book. And you can even, say, add custom
flags to the regex without complicating shared code.
Right, and it's all duplicate. Just look in his patch how many times
fuzzy.digits is used. What's going to happen is someone is going to come
along later and say Geez, we have a ton of some_regex =
re.compile('\d+'), I should make a macro thinger out of this and we're
back where we started.
The rest of Fuzzy functionality consists of strict type checking (which
isn't really necessary in integration tests), and the ability to call
arbitrary callables (which is just the scope creep I was talking about).
By the way, in current tests these features are hardly ever used in
combination.
Here we agree. I'd prefer to keep Fuzzy limited to just simple regex and
woudln't object to delegating the other enforcement to something else.
Even if this extra functionality is necessary, it's orthogonal to regex
matching and can be more cleanly done with several separate asserts.
Unless you need a single declarative object to compare against, of course.
Yup.
That isn't to say that Fuzzy isn't being abused, but that is also the
responsibility of the reviewers to be strict about.
Then perhaps I'm too strict, but I say that using it outside of the
declarative tests is abuse.
Especially if it takes six patches with hundreds of changed lines to
repurpose Fuzzy for integration tests (but that's not part of -1 to the
idea).
That is hardly fair. The bulk of the patches just change imports.
So to summarize, I think:
- Fuzzy should remain as a regex should remain as a regex shortcut
- The non-regex features can be moved elsewhere
- I don't really have a handle on how he intended to use this for
integration testing, so I don't have an opinion here. But I'd expect
that most integration tests depend more on return values than comparing
against known good.
rob
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Improve FreeIPA usability in cloud environments
On Mon, 2013-09-16 at 09:31 +0200, Petr Spacek wrote: You are right, the scenario described by me doesn't require views. Please see reply from James in another part of this thread - his setup has shared host name (internal = external) but different IP addresses for internal and external usage. The question is if DNS is the right layer to solve the problem. Yep. See below. Some oddities like this could be solved on IP routing level: I.e. use 'external'/public IP address everywhere and route packets with this 'external IP' to the right part of the internal network. Solution on routing layer can be technically feasible, but it doesn't mean that it is politically acceptable. People usually don't want to touch routing unless absolutely necessary :-) FWIW, I completely agree, although I do not having a problem with the routing solution, in certain setups it can add much more complexity which may not be required or even possible to do. Eg: conntrackd setups could get hairy or impossible. Let's do this in DNS. James PS: If anyone wants to meet to talk about this, I'm at Linuxcon New Orleans this week if I can be of any help. signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0094-0099 Make Fuzzy objects available for the whole ipatests module
On 09/16/2013 02:36 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
On 09/13/2013 07:04 PM, Rob Crittenden wrote:
[...]
Replacing it would either a) replicate its functionality almost
completely or b) spread duplicate regex code all over the place.
I'd go for b; spreading this code:
import re
some_regex = re.compile('some.*regex$')
...
assert some_regex.search(x)
instead of:
from wherever import Fuzzy
warm_fuzzy = Fuzzy('some.*regex$')
...
assert x == warm_fuzzy
all over the place is fine in my book. And you can even, say, add custom
flags to the regex without complicating shared code.
Right, and it's all duplicate. Just look in his patch how many times
fuzzy.digits is used. What's going to happen is someone is going to come
along later and say Geez, we have a ton of some_regex =
re.compile('\d+'), I should make a macro thinger out of this and we're
back where we started.
The first two lines only need to be there once, in the other files you
can just import some_regex, the same way you can import the Fuzzy object.
The rest of Fuzzy functionality consists of strict type checking (which
isn't really necessary in integration tests), and the ability to call
arbitrary callables (which is just the scope creep I was talking about).
By the way, in current tests these features are hardly ever used in
combination.
Here we agree. I'd prefer to keep Fuzzy limited to just simple regex and
woudln't object to delegating the other enforcement to something else.
The type checking is actually a big part of Fuzzy functionality, since
in the API we want all non-binary strings to be unicode and not str.
That isn't to say that Fuzzy isn't being abused, but that is also the
responsibility of the reviewers to be strict about.
Then perhaps I'm too strict, but I say that using it outside of the
declarative tests is abuse.
Especially if it takes six patches with hundreds of changed lines to
repurpose Fuzzy for integration tests (but that's not part of -1 to the
idea).
That is hardly fair. The bulk of the patches just change imports.
The patches make Fuzzy enforce basestring type by default, instead of
unicode. But in the IPA API we normally want only unicode, so almost all
*usages* of Fuzzy are then changed to enforce unicode.
That is bad because IMO Fuzzy is specific to the declarative API tests
and should have defaults made for them.
So to summarize, I think:
- Fuzzy should remain as a regex should remain as a regex shortcut
- The non-regex features can be moved elsewhere
- I don't really have a handle on how he intended to use this for
integration testing, so I don't have an opinion here. But I'd expect
that most integration tests depend more on return values than comparing
against known good.
We're getting closer to an agreement :)
- Fuzzy should remain as a regex should remain as a regex shortcut *for
our declarative tests which need type-checking*
- The non-regex *and non-typechecking* features can be moved elsewhere
(they actually are: assert_deepequal allows plain callables, it's just a
matter of using that in the tests and then removing the functionality
from Fuzzy)
- In integration testing, if we do need to check the output of commands,
we don't really care about the bytes/unicode distinction, so the re
module is enough.
--
Petr³
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNS improvements: Should we add some sanity checking?
On Mon, 2013-09-16 at 09:45 +0200, Petr Spacek wrote: On 16.9.2013 09:06, Martin Kosek wrote: On 09/13/2013 06:17 PM, Simo Sorce wrote: On Fri, 2013-09-13 at 09:29 +0200, Petr Spacek wrote: Hello list, Jan Pazdziora jpazdzi...@redhat.com proposed that 'ipa dns*' commands should do some sanity checking/waiting after the record is added to LDAP. I think that it could be valuable and I would like to get opinions from freeipa-devel list. === The problem === ipa dnsrecord-add and similar commands add the data to LDAP, but it doesn't mean that the data are *immediately* resolvable via DNS protocol. Note that data from LDAP are *asynchronously* read and processed by Named and the time when records are available is not predictable. A mismatch between LDAP can be caused by some connection problem between DNS and LDAP servers, LDAP or DNS server restart, or simply by a bug in DNS-LDAP synchronization code. (This is becomming more and more important if we consider the whole DNSSEC effort and related re-factoring.) My experience is that users are very confused if the ipa dnsrecord-add command says 'record added' but it is still not available via DNS. It is really hard to debug when you see the problem first 10 times :-) === The proposal === 1. Let FreeIPA framework to change DNS data in LDAP as we do now. 2. After each change, do DNS queries for changed record and wait until the new data are available. IMHO it is very cheap operation (in usual cases 1 DNS packet back and forth) and it would save a lot of headaches to users and support. This will naturally catch the case where named crashes after the change etc. === Expected outcome === There will not be any failure like this: $ ipa-adtrust-install $ ipa dnszone-add $AD_DOMAIN --name-server=advm.$AD_DOMAIN --admin-email=hostmaster@$AD_DOMAIN.com --force --forwarder=$AD_IP --forward-policy=only --ip-address=$AD_IP Zone name: dom123.example.com [...] $ ipa trust-add --type=ad DOM123.EXAMPLE.COM --admin Administrator --password Password for ad...@dom123.example.com: ipa: ERROR: Cannot find specified domain or server name Would it make sense to change the code to use dynDNS update to add records ? Wouldn't that force named to be in sync ? Simo. Switching from LDAP modify operation to dynDNS update seems as a too big change to me. If nothing else, it would not fly with our LDAP ACI/permission system and ability to delegate DNS read/write rights to somebody else. I can see pros and cons for both ways: LDAP: + we have the code :-) + ACI magic - works only with bind-dyndb-ldap - can get out of sync (bugs, timeouts etc.) Standard DNS updates: + can work with any DNS server + with AD integration, we could use existing AD DNS infrastructure: i.e. manage DNS records for FreeIPA servers and host without deploying a new DNS server and related 'politics' + bind-dyndb-ldap is not necessary (ouh, my work is useless now :-)) - we don't have the code in FreeIPA framework - ACI magic is not available (in reality, it depends on the DNS server) - reading of current state could be more complex for user interface (On the other hand, current user interface doesn't show real state of thing because LDAP != DNS.) I forgot one thing that breaks, we cannot create new zones via dyndns, so we'd still have a mixed set. But I was thinking about your pros too, esp being able to use an AD DNS if necessary (evil but doable). I do not want to insist, because I also agree with Martin, but we should think about it. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCHES 100-106] Initial implementation of AD integration tests
Hi,
this set of patches extends ipatests module to support integration
testing with Active Directory,
as well as provides an basic (working without artificial sleeps!) trust
test case.
--
Tomas Babej
Associate Software Engeneer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org
From 793dfd9dc33ef8387761e68058c9e8c9b07c3015 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 4 Sep 2013 14:12:28 +0200
Subject: [PATCH 100/106] ipatests: Add Active Directory support to
configuration
---
ipatests/test_integration/config.py | 21 +
1 file changed, 21 insertions(+)
diff --git a/ipatests/test_integration/config.py b/ipatests/test_integration/config.py
index d43812c514bf1c9d23740e6f75cc3574235e86d3..ac0131e435d33b6730093cbc64a1b47910d3971e 100644
--- a/ipatests/test_integration/config.py
+++ b/ipatests/test_integration/config.py
@@ -1,5 +1,6 @@
# Authors:
# Petr Viktorin pvikt...@redhat.com
+# Tomas Babej tba...@redhat.com
#
# Copyright (C) 2013 Red Hat
# see file 'COPYING' for use and warranty information
@@ -50,11 +51,14 @@ class Config(object):
self.nis_domain = kwargs.get('nis_domain') or 'ipatest'
self.ntp_server = kwargs.get('ntp_server') or (
'%s.pool.ntp.org' % random.randint(0, 3))
+self.ad_admin_name = kwargs.get('ad_admin_name') or 'Administrator'
+self.ad_admin_password = kwargs.get('ad_admin_password') or 'Secret123'
if not self.root_password and not self.root_ssh_key_filename:
self.root_ssh_key_filename = '~/.ssh/id_rsa'
self.domains = []
+self.ad_domains = []
@classmethod
def from_env(cls, env):
@@ -76,6 +80,8 @@ class Config(object):
ADMINPW: Administrator password
ROOTDN: Directory Manager DN
ROOTDNPWD: Directory Manager password
+ADADMINID: Active Directory Administrator username
+ADADMINPW: Active Directory Administrator password
DNSFORWARD: DNS forwarder
NISDOMAIN
NTPSERVER
@@ -83,6 +89,7 @@ class Config(object):
MASTER_env1: FQDN of the master
REPLICA_env1: space-separated FQDNs of the replicas
CLIENT_env1: space-separated FQDNs of the clients
+AD_env1: space-separated FQDNs of the Active Directories
OTHER_env1: space-separated FQDNs of other hosts
(same for _env2, _env3, etc)
BEAKERREPLICA1_IP_env1: IP address of replica 1 in env 1
@@ -104,13 +111,23 @@ class Config(object):
dns_forwarder=env.get('DNSFORWARD'),
nis_domain=env.get('NISDOMAIN'),
ntp_server=env.get('NTPSERVER'),
+ ad_admin_name=env.get('ADADMINID'),
+ ad_admin_password=env.get('ADADMINPW'),
)
+# Either IPA master or AD can define a domain
+
domain_index = 1
while env.get('MASTER_env%s' % domain_index):
self.domains.append(Domain.from_env(env, self, domain_index))
domain_index += 1
+domain_index = 1
+while env.get('AD_env%s' % domain_index):
+self.ad_domains.append(Domain.from_env(env, self, domain_index,
+ ad_domain=True))
+domain_index += 1
+
return self
def to_env(self, simple=True):
@@ -133,6 +150,9 @@ class Config(object):
env['ROOTDN'] = str(self.dirman_dn)
env['ROOTDNPWD'] = self.dirman_password
+env['ADADMINID'] = self.ad_admin_name
+env['ADADMINPW'] = self.ad_admin_password
+
env['DNSFORWARD'] = self.dns_forwarder
env['NISDOMAIN'] = self.nis_domain
env['NTPSERVER'] = self.ntp_server
@@ -145,6 +165,7 @@ class Config(object):
for role, hosts in [('MASTER', domain.masters),
('REPLICA', domain.replicas),
('CLIENT', domain.clients),
+('AD', domain.ads),
('OTHER', domain.other_hosts)]:
hostnames = ' '.join(h.hostname for h in hosts)
env['%s%s' % (role, domain._env)] = hostnames
--
1.8.3.1
From b9dcf30106d5d4913357cf0e70c5d6c4b2e7ba50 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 4 Sep 2013 14:24:41 +0200
Subject: [PATCH 101/106] ipatests: Extend domain object with 'ad' role support
and WinHosts
---
ipatests/test_integration/config.py | 39 +++--
1 file changed, 20 insertions(+), 19 deletions(-)
diff --git a/ipatests/test_integration/config.py b/ipatests/test_integration/config.py
index ac0131e435d33b6730093cbc64a1b47910d3971e..284b511ac93061b44ca612bed006338fb001833c 100644
--- a/ipatests/test_integration/config.py
+++ b/ipatests/test_integration/config.py
@@ -27,7 +27,7 @@ import random
from ipapython import ipautil
from ipapython.dn
Re: [Freeipa-devel] Newcomer's question
Исаев Виталий Анатольевич wrote: Dear Free IPA developers, Our team is working on the project based on the RHEL Virtualization and RHEL IdM server. It’s planned to run our software in enclosed internal enterprise network, and we would like to assign all the authentication and authorization tasks to the FreeIPA Python API. In fact we have already written this part of project on plain C; dialog with IdM server has been implemented over SSH interaction (libssh API + GNU flex). But some time ago we discovered FreeIPA API and since then we really want to migrate from C to Python. So the time has come, but the problem is our complete ignorance of the Python programming language. We faced a problem trying to modify the tutorial script */free-ipa-3.3.1/doc/python-api.py: /*ldap2 was refused to import. Which module should be included in this case? We use RHEL 6.4 desktop, all the IPA packages has 3.0.0-25 version. #!/usr/bin/python # -*- coding: utf-8 -*- from ipalib import api, errors from ipalib import Command from ipalib import Object from ipalib import Str from ipalib import output from ipalib.plugins import baseldap #Load environment api.finalize() if api.env.in_server: api.Backend.ldap2.connect( ccache=api.Backend.krb.default_ccname() ) else: api.Backend.xmlclient.connect() #Execute command dn = api.Backend.ldap2.make_dn_from_attr(u'python_dev3', loginshell=u'/bin/sh', givenname=u'Python', sn=u'User', userpassword=u'redhat') try: api.Backend.user_add(dn) excepterrors.DuplicateEntry: print(Possibly duplicate…) else: print(User added…) Errors: ipa: INFO: trying https://ipa.dev.ru/ipa/xml Traceback (most recent call last): File ./test.py, line 22, in module dn = api.Backend.ldap2.make_dn_from_attr(u'python_dev3', loginshell=u'/bin/sh', givenname=u'Python', sn=u'User', userpassword=u'redhat') AttributeError: 'NameSpace' object has no attribute 'ldap2' Try this: from ipalib import api from ipalib import errors api.bootstrap(context='cli') api.finalize() api.Backend.xmlclient.connect() try: api.Command['user_add'](u'testuser', givenname=u'Test', sn=u'User', loginshell=u'/bin/sh') except errors.DuplicateEntry: print user already exists else: print User added ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 451-458 Web UI devel and source code documentation
On 09/11/2013 12:44 PM, Petr Vobornik wrote: Hello, This is a part of documentation effort which started couple month ago. Attached patches improves devel documentation of Web UI. Mostly by annotating source code and then processing it by JSDuck tool[1]. The documentation is not complete - most plugins and member of some core widgets and facets are not annotated yet. I'm sending it now because I need to focus on more pressing tickets. You can see current state at my fedorapeople page [2]. I also converted 5 guides/articles which I wrote some time ago. Guides are also part of the JSDuck app [3]. The idea is to regularly generate the doc and place it on docs.freeipa.org (not in production at the moment) so all doc would be on one place. Installation of JSDuck is documented on their page [4]. Basically it requires ruby and JSDuck gem. Usage: $ cd install/ui/doc $ make Documentation is generated into: install/ui/build/code_doc directory [1] https://github.com/senchalabs/jsduck [2] http://pvoborni.fedorapeople.org/doc [3] http://pvoborni.fedorapeople.org/doc/#!/guide [4] https://github.com/senchalabs/jsduck/wiki/Installation ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I looked into the documentation effort and (ruby dependency discussion aside) I don't have any major objections. I like how the generated pages look, and they are intuitive and easy to navigate. A couple of nitpicks: 1) There are some spelling mistakes (e.g. Apllication_controller) 2) Bulleted lists are not rendered nicely in the html output (see for example the doc string for _base.Builder property 'string_mode'. I think a list needs to look like this in the source code: /** * This is a list: * * - 'element1' * - 'element2' * */ as opposed to this: /** * This is a list: * - 'element1' * - 'element2' */ -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Off Topic, was: [PATCH 0017] Add OTP support to ipalib CLI
On Sep 14, 2013, at 10:25 AM, Simo Sorce s...@redhat.com wrote:
On Fri, 2013-09-13 at 15:06 -0700, Henry B. Hotz wrote:
On Sep 13, 2013, at 11:38 AM, Dmitri Pal d...@redhat.com wrote:
, ipatokenotpalgorithm
Uses default TOTP we do not support more for now. In future it will be a
global policy I assume.
This is just me, like the sig says.
I would advocate for HOTP, with a bunch of special processing for
token counter regression.
If the token seed and current counter are stolen by a bad guy, and
actually used, then at some point the bad guy or the real user are
going to attempt an authentication using a value that's old. This
presents an opportunity to detect that the theft took place.
I regard this as a real, useful security feature which is not possible
with time-based tokens, provided the verification infrastructure is
set up to do the detection, and to take some action when the detection
occurs. If the theft is done by a smart-enough adversary, there may
be nothing to prevent them from resynchronizing the legitimate copy of
the soft-token when they use it, but it still seems like a worthwhile
capability. It would detect the most obvious token-theft scenarios.
Obviously, this is out-of-scope for any of your current efforts, but I
wanted to throw it in the mix for possible future work.
Henry,
Thanks a lot for bringing this up.
I have to say that I never liked HOTP due to the burden it takes to
correctly manage them compared to TOTP and the hardest work around
synchronization. The worst part of it being the need to write AND
synchronize across the infrastructure at every authentication attempt
(replication). Something that could easily bring the whole
infrastructure to its knees at busy hours.
I won't pretend that's not a big issue. However if you want to prevent re-use
of time-based tokens, then you have the same problem.
RSA allows you to prevent re-use. However I've been told it doesn't scale
well, performance wise. In particular you can't distinguish an automatic retry
(like kinit would do after 1 second), from a hostile re-use (steal token in
transit and use it yourself before it expires).
I've also been told by people who did it that if you wanted to actually deploy
the old SAM protocol you realistically had to configure RSA to allow re-use.
Otherwise the client might retry before the first response arrived, and all
subsequent responses would be failures.
Substituting FAST/OTP for SAM doesn't change anything in the back-end exchange
and performance. Someone commented that using TCP instead of UDP was useful
for exactly those reasons, and that wasn't available back then.
However HOTP has obvious advantages when it comes to identifying attack
attempts, so I'll start thinking hard how to deal with it wrt
performance.
Simo.
There seems to be some interest in dealing with it in Heimdal. I'd like to
build the OTP service directly into the kdc so you can use {H,T}OTP directly
with the old timestamp or FAST/encrypted challenge, but I seem to be a serious
minority on this point.
If you export the OTP processing, then you export the
performance/synchronization issues.
--
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Off Topic, was: [PATCH 0017] Add OTP support to ipalib CLI
On Sep 15, 2013, at 11:17 AM, Dmitri Pal d...@redhat.com wrote: On 09/13/2013 06:06 PM, Henry B. Hotz wrote: On Sep 13, 2013, at 11:38 AM, Dmitri Pal d...@redhat.com wrote: , ipatokenotpalgorithm Uses default TOTP we do not support more for now. In future it will be a global policy I assume. This is just me, like the sig says. I would advocate for HOTP, with a bunch of special processing for token counter regression. If the token seed and current counter are stolen by a bad guy, and actually used, then at some point the bad guy or the real user are going to attempt an authentication using a value that's old. This presents an opportunity to detect that the theft took place. I regard this as a real, useful security feature which is not possible with time-based tokens, provided the verification infrastructure is set up to do the detection, and to take some action when the detection occurs. If the theft is done by a smart-enough adversary, there may be nothing to prevent them from resynchronizing the legitimate copy of the soft-token when they use it, but it still seems like a worthwhile capability. It would detect the most obvious token-theft scenarios. Obviously, this is out-of-scope for any of your current efforts, but I wanted to throw it in the mix for possible future work. Count creates an overhead in the replicated environment. Effectively you need to replicate count on every authentication, this is a big cost. While it is more secure for the case you suggest it does not seem to be a good enough justification for the replication overhead. If stolen the chance that it will be used some tine later is really slim. It most likely will be used right away so the old code detection will be irrelevant. But we anticipate that there will be cases when HOTP will be needed, so we do not preclude implementing it in future but on the other hand do not see it as an immediate goal either. If the bad guy uses the stolen seed immediately, yes it works. However it advances the service's counter so the legitimate user will trip the monitor whenever he/she next uses the token. In other words the monitor will tell you of a problem, but it won't tell you if the user that demonstrated the problem was the good guy or the bad guy. It also won't help if the good guy never uses the token at all after the theft. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Debian client support
On 09/03/2013 11:00 AM, Petr Viktorin wrote: On 09/02/2013 11:43 PM, Timo Aaltonen wrote: This fixes https://fedorahosted.org/freeipa/ticket/1887 and https://fedorahosted.org/freeipa/ticket/2455 Thank you! the first three patches fix some bugs in how python is used These look okay, I'll check when other build errors are fixed. [...] fifth fixes some compilation warnings Looks good to my eyes, perhaps a C expert can look at this one too. I wonder why these warnings aren't enabled in our builds, though. I've built and checked patches 1, 2, 3, 5 now, and found no regressions. I've asked Rob about why IPA explicitly disallowed to load plugins from symlinks. That code's author is not around anymore. The reason seems to be vague concerns about security, but I think we have better things to worry about than admins (or distros) that symlink from /usr/lib/** to untrusted places. (For the record: AFAIK, Debian uses symlinks for all Python modules, so distro-installed plugins will be symlinks.) ACK to those 4 patches, pushed to master: 8c03b1dbcdf75ba76b96ccfcc148afe0e134e2d3 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Newcomer's question
Dear Free IPA developers, Our team is working on the project based on the RHEL Virtualization and RHEL IdM server. It's planned to run our software in enclosed internal enterprise network, and we would like to assign all the authentication and authorization tasks to the FreeIPA Python API. In fact we have already written this part of project on plain C; dialog with IdM server has been implemented over SSH interaction (libssh API + GNU flex). But some time ago we discovered FreeIPA API and since then we really want to migrate from C to Python. So the time has come, but the problem is our complete ignorance of the Python programming language. We faced a problem trying to modify the tutorial script free-ipa-3.3.1/doc/python-api.py: ldap2 was refused to import. Which module should be included in this case? We use RHEL 6.4 desktop, all the IPA packages has 3.0.0-25 version. #!/usr/bin/python # -*- coding: utf-8 -*- from ipalib import api, errors from ipalib import Command from ipalib import Object from ipalib import Str from ipalib import output from ipalib.plugins import baseldap #Load environment api.finalize() if api.env.in_server: api.Backend.ldap2.connect( ccache=api.Backend.krb.default_ccname() ) else: api.Backend.xmlclient.connect() #Execute command dn = api.Backend.ldap2.make_dn_from_attr(u'python_dev3', loginshell=u'/bin/sh', givenname=u'Python', sn=u'User', userpassword=u'redhat') try: api.Backend.user_add(dn) except errors.DuplicateEntry: print(Possibly duplicate...) else: print(User added...) Errors: ipa: INFO: trying https://ipa.dev.ru/ipa/xml Traceback (most recent call last): File ./test.py, line 22, in module dn = api.Backend.ldap2.make_dn_from_attr(u'python_dev3', loginshell=u'/bin/sh', givenname=u'Python', sn=u'User', userpassword=u'redhat') AttributeError: 'NameSpace' object has no attribute 'ldap2' Thank you, Виталий Исаев Инженер-программист Группа разработки и внедрения ПСЗИ Департамент информационной безопасности ОАО Финтех ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNS improvements: Should we add some sanity checking?
On 09/16/2013 09:32 AM, Simo Sorce wrote: On Mon, 2013-09-16 at 09:45 +0200, Petr Spacek wrote: On 16.9.2013 09:06, Martin Kosek wrote: On 09/13/2013 06:17 PM, Simo Sorce wrote: On Fri, 2013-09-13 at 09:29 +0200, Petr Spacek wrote: Hello list, Jan Pazdziora jpazdzi...@redhat.com proposed that 'ipa dns*' commands should do some sanity checking/waiting after the record is added to LDAP. I think that it could be valuable and I would like to get opinions from freeipa-devel list. === The problem === ipa dnsrecord-add and similar commands add the data to LDAP, but it doesn't mean that the data are *immediately* resolvable via DNS protocol. Note that data from LDAP are *asynchronously* read and processed by Named and the time when records are available is not predictable. A mismatch between LDAP can be caused by some connection problem between DNS and LDAP servers, LDAP or DNS server restart, or simply by a bug in DNS-LDAP synchronization code. (This is becomming more and more important if we consider the whole DNSSEC effort and related re-factoring.) My experience is that users are very confused if the ipa dnsrecord-add command says 'record added' but it is still not available via DNS. It is really hard to debug when you see the problem first 10 times :-) === The proposal === 1. Let FreeIPA framework to change DNS data in LDAP as we do now. 2. After each change, do DNS queries for changed record and wait until the new data are available. IMHO it is very cheap operation (in usual cases 1 DNS packet back and forth) and it would save a lot of headaches to users and support. This will naturally catch the case where named crashes after the change etc. === Expected outcome === There will not be any failure like this: $ ipa-adtrust-install $ ipa dnszone-add $AD_DOMAIN --name-server=advm.$AD_DOMAIN --admin-email=hostmaster@$AD_DOMAIN.com --force --forwarder=$AD_IP --forward-policy=only --ip-address=$AD_IP Zone name: dom123.example.com [...] $ ipa trust-add --type=ad DOM123.EXAMPLE.COM --admin Administrator --password Password for ad...@dom123.example.com: ipa: ERROR: Cannot find specified domain or server name Would it make sense to change the code to use dynDNS update to add records ? Wouldn't that force named to be in sync ? Simo. Switching from LDAP modify operation to dynDNS update seems as a too big change to me. If nothing else, it would not fly with our LDAP ACI/permission system and ability to delegate DNS read/write rights to somebody else. I can see pros and cons for both ways: LDAP: + we have the code :-) + ACI magic - works only with bind-dyndb-ldap - can get out of sync (bugs, timeouts etc.) Standard DNS updates: + can work with any DNS server + with AD integration, we could use existing AD DNS infrastructure: i.e. manage DNS records for FreeIPA servers and host without deploying a new DNS server and related 'politics' + bind-dyndb-ldap is not necessary (ouh, my work is useless now :-)) - we don't have the code in FreeIPA framework - ACI magic is not available (in reality, it depends on the DNS server) - reading of current state could be more complex for user interface (On the other hand, current user interface doesn't show real state of thing because LDAP != DNS.) I forgot one thing that breaks, we cannot create new zones via dyndns, so we'd still have a mixed set. But I was thinking about your pros too, esp being able to use an AD DNS if necessary (evil but doable). I do not want to insist, because I also agree with Martin, but we should think about it. ... and not rush Simo. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Off Topic, was: [PATCH 0017] Add OTP support to ipalib CLI
On 09/16/2013 06:04 PM, Henry B. Hotz wrote:
On Sep 14, 2013, at 10:25 AM, Simo Sorce s...@redhat.com wrote:
On Fri, 2013-09-13 at 15:06 -0700, Henry B. Hotz wrote:
On Sep 13, 2013, at 11:38 AM, Dmitri Pal d...@redhat.com wrote:
, ipatokenotpalgorithm
Uses default TOTP we do not support more for now. In future it will be a
global policy I assume.
This is just me, like the sig says.
I would advocate for HOTP, with a bunch of special processing for
token counter regression.
If the token seed and current counter are stolen by a bad guy, and
actually used, then at some point the bad guy or the real user are
going to attempt an authentication using a value that's old. This
presents an opportunity to detect that the theft took place.
I regard this as a real, useful security feature which is not possible
with time-based tokens, provided the verification infrastructure is
set up to do the detection, and to take some action when the detection
occurs. If the theft is done by a smart-enough adversary, there may
be nothing to prevent them from resynchronizing the legitimate copy of
the soft-token when they use it, but it still seems like a worthwhile
capability. It would detect the most obvious token-theft scenarios.
Obviously, this is out-of-scope for any of your current efforts, but I
wanted to throw it in the mix for possible future work.
Henry,
Thanks a lot for bringing this up.
I have to say that I never liked HOTP due to the burden it takes to
correctly manage them compared to TOTP and the hardest work around
synchronization. The worst part of it being the need to write AND
synchronize across the infrastructure at every authentication attempt
(replication). Something that could easily bring the whole
infrastructure to its knees at busy hours.
I won't pretend that's not a big issue. However if you want to prevent
re-use of time-based tokens, then you have the same problem.
RSA allows you to prevent re-use.
RSA used Lock Manager (6.x) or Adjudicator (7.x).
The idea is the same: fast replication of the interval that the code
corresponds to. Other replicas have to check before trying to lock the
same interval. It scales more or less but very complex.
However I've been told it doesn't scale well, performance wise. In
particular you can't distinguish an automatic retry (like kinit would do
after 1 second), from a hostile re-use (steal token in transit and use it
yourself before it expires).
We changed the kerberos client library to have longer retries.
I've also been told by people who did it that if you wanted to actually
deploy the old SAM protocol you realistically had to configure RSA to allow
re-use. Otherwise the client might retry before the first response arrived,
and all subsequent responses would be failures.
Yes so we fixed the kerberos client to not retry that quickly in TCP
case. This patch was submitted last spring.
Substituting FAST/OTP for SAM doesn't change anything in the back-end
exchange and performance.
I do not remember the details of the patch described above, i.e. was it
generic or for OTP case only.
Someone commented that using TCP instead of UDP was useful for exactly those
reasons, and that wasn't available back then.
Now it is.
However HOTP has obvious advantages when it comes to identifying attack
attempts, so I'll start thinking hard how to deal with it wrt
performance.
Simo.
There seems to be some interest in dealing with it in Heimdal. I'd like to
build the OTP service directly into the kdc so you can use {H,T}OTP directly
with the old timestamp or FAST/encrypted challenge, but I seem to be a
serious minority on this point.
If you export the OTP processing, then you export the
performance/synchronization issues.
--
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
