Re: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'}

[Petr Spacek]

On 21.12.2016 21:36, Brian J. Murrell wrote:
> Some additional information.  I can't seem to use the CLI either. 
> Perhaps that is expected:
> 
> # kinit admin
> Password for ad...@example.com:
> 
> # klist
> Ticket cache: KEYRING:persistent:0:krb_ccache_3jm4X9m
> Default principal: ad...@example.com
> 
> Valid starting ExpiresService principal
> 21/12/16 15:29:20  22/12/16 15:29:17  krbtgt/example@example.com
> 
> # ipa host-find
> ipa: ERROR: Insufficient access:  Invalid credentials
> 
> When I do that (the ipa host-find) /var/log/krb5kdc.log says:
> 
> Dec 21 15:29:28 server.example.com krb5kdc[13548](info): TGS_REQ (6 etypes 
> {18 17 16 23 25 26}) fd31:aeb1:48df:0:214:d1ff:fe13:45ac: ISSUE: authtime 
> 1482352160, etypes {rep=18 tkt=18 ses=18}, ad...@example.com for 
> HTTP/server.example@example.com
> Dec 21 15:29:28 server.example.com krb5kdc[13548](info): closing down fd 12
> Dec 21 15:29:28 server.example.com krb5kdc[13548](info): TGS_REQ (6 etypes 
> {18 17 16 23 25 26}) fd31:aeb1:48df:0:214:d1ff:fe13:45ac: ISSUE: authtime 
> 1482352160, etypes {rep=18 tkt=18 ses=18}, 
> HTTP/server.example@example.com for ldap/server.example@example.com
> Dec 21 15:29:28 server.example.com krb5kdc[13548](info): ... 
> CONSTRAINED-DELEGATION s4u-client=ad...@example.com
> Dec 21 15:29:28 server.example.com krb5kdc[13548](info): closing down fd 12
> 
> Not sure if that's helpful or not but it's something new (to me) so I
> thought I would add it to the case.
> 
> Most unfortunately I need to access IPA to do some configuration
> changes so this is getting more unfortunate than just some errors in a
> log now.  :-(

Yes, this will be manifestation of the same problem. Interestingly the LDAP
server should use the ds.keytab file instead of krb5.keytab.

We need someone from DS team of with deep Kerberos/gssproxy knowledge to look
into it.

Simo, Ludwig, how can this happen?

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'}

[Petr Spacek]

Okay, I believe that this is the problem:

On 21.12.2016 15:53, Brian J. Murrell wrote:
> [21/Dec/2016:09:39:12.003351818 -0500] conn=77028 fd=107 slot=107 connection 
> from local to /var/run/slapd-EXAMPLE.COM.socket
...
> [21/Dec/2016:09:39:12.064476101 -0500] conn=77028 op=0 BIND dn="" method=sasl 
> version=3 mech=GSSAPI
> [21/Dec/2016:09:39:12.067486416 -0500] conn=77028 op=0 RESULT err=49 tag=97 
> nentries=0 etime=0 - SASL(-1): generic failure: GSSAPI Error: Unspecified GSS 
> failure.  Minor code may provide more information (Permission denied)
> [21/Dec/2016:09:39:12.192506861 -0500] conn=77028 op=1 UNBIND
> [21/Dec/2016:09:39:12.192549740 -0500] conn=77028 op=1 fd=107 closed - U1

I have no idea why it is returning Permission denied.

Is it reproducible when you run this?
$ kinit -kt /etc/ipa/dnssec/ipa-dnskeysyncd.keytab
ipa-dnskeysyncd/server.example.com
$ ldapsearch -Y GSSAPI -H /var/run/slapd-EXAMPLE.COM.socket
?

We need to find out why it is blowing up on GSSAPI negotiation.

Wild guess is that /etc/dirsrv/ds.keytab could have wrong permissions. It
should have
-rw---. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0

If you manage to reproduce it, you can attach strace to the running dirsrv
process and see what call is failing (if it is a system call)...

I'm CCing LDAP server gurus to see if it rings a bell.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'}

[Petr Spacek]

On 20.12.2016 12:41, Brian J. Murrell wrote:
> On Tue, 2016-12-20 at 11:55 +0100, Martin Basti wrote:
>>
>> So there are actually no issues with credentials, it needs more 
>> debugging, in past we have similar case but we haven't found the
>> root 
>> cause why it doesn't have the right credentials after kinit.
> 
> So, to be clear, all I did was kinit.  I didn't do anything after that
> once the credentials were acquired. Should I have or did you just want
> me to test that credential file was usable?  I did that as root. 
> Here's the permissions on that keytab just in case there is a problem
> there:
> 
> # ls -lZ /etc/ipa/dnssec/ipa-dnskeysyncd.keytab
> -r--r-. root ods unconfined_u:object_r:etc_t:s0   
> /etc/ipa/dnssec/ipa-dnskeysyncd.keytab
> 
> restorecon says that the selinux labels are ok.  The file is not in the
> RPM (i.e. as a config file) so I have no reference for the permissions
> of it.
> 
>> Are you 
>> willing to do more basic level code debugging?
> 
> Absolutely.
> 
>> BTW this is used only with DNSSEC feature. I you don't use DNSSEC 
>> signing you can ignore this failing service (ipactl start 
>> --ignore-service-failures)
> 
> Let's also not lose sight of the other problem that occurred at the
> same upgrade and that's the having to fall back to simple
> authentication of bind with:
> 
> arg "auth_method simple";
> arg "bind_dn uid=admin,cn=users,cn=accounts,dc=example.com";
> arg "password my_password";
> 
> in /etc/named.conf due to:
> 
> 21:12:19 LDAP error: Invalid credentials: bind to LDAP server failed
> 
> trying to start bind via systemctl start ipa.
> 
> Is it most likely that these two problems are in fact not related?

I guess that they are related because it is basically the very same problem.
The keytab does not work when used from the server application.

The question is: Why is that?

You can try to add line
KRB5_TRACE=/dev/stdout
to
/etc/sysconfig/ipa-dnskeysyncd

and see if there will be some additional information in the the journal.

Maybe you will have to use path like /var/lib/ipa/dnssec/debug.log instead of
/dev/stderr and then look into the new file.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[Petr Spacek]

On 8.12.2016 10:12, Pieter Nagel wrote:
> On Thu, Dec 8, 2016 at 10:59 AM, Alexander Bokovoy 
> wrote:
> 
>> It is really simply: your DNS domain named as your Kerberos realm must
>> be under your control, one way or another, to allow automatic discovery
>> of resources to work.
>>
> 
> Thanks, this explanation makes it crystal clear. This exact phrasing would
> have made the docs much clearer too, IMO.
> 
> Setting the realm to the DNS domain that the FreeIPA internal DNS server
> serves is just one simple out-of-the box way to get DNS domain named as
> your Kerberos realm that is under your control, in other words.

I've tried to clarify things in man pages and on web as well. Please have a
look to changes and let us know if it is better or not, and preferably what
can be improved and in which way

The modified deployment page is here:
http://www.freeipa.org/page/Deployment_Recommendations

Man page changes and changes in description of installer options are here:
https://github.com/freeipa/freeipa/pull/352

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Kerberos realm for different domain

[Petr Spacek]

On 15.12.2016 23:59, Brian Candler wrote:
>> On Sun, Dec 11, 2016 at 11:31 PM, David Kupka > > wrote:
>>
>>
>> yes you can do it. DNS domain and Kerberos realm are two different
>> things. It's common and AFAIK recommended to capitalize DNS domain
>> to get the realm but it's not required.
>> If you really want to have them different make sure:
>> a) anotherdomain.com  is under your
>> control,
>> b) you don't already have other Kerberos instance (FreeIPA, MIT
>> KRB5, MS AD, ...) with ANOTHERDOMAIN.COM
>>  realm deployed.
>>
>> With FreeIPA you can run
>> # ipa-server-install --domain example.com
>>  --realm ANOTHERDOMAIN.COM
>> 
>>
>> But before you do, why do you want to have the realm different
>> from the domain?
>>
>>
> 
> Question: what "domain" does the --domain option to ipa-server-install
> actually refer to?
> 
> The man page just says " Your DNS domain name". But what does it actually 
> alter?
> 
> 1. the DNS domain which holds the kerberos realm location information? I don't
> think so; I think if you are searching for realm FOO.COM you'll always look in
> the DNS under "foo.com", that's a fixed relationship.
> 
> 2. the DNS name of the IPA server itself? But if set up correctly, it already
> has an FQDN (as reported by "hostname -f"). And if you give the "--hostname"
> option, that's a FQDN not a bare hostname.
> 
> 3. the DNS zone which IPA is authoritative for? But you can run IPA without
> integrated DNS.
> 
> 4. the LDAP base DN? I guess that could be it: e.g. "--domain foo.com" puts
> everything under tree "dc=foo,dc=com"?
> 
> 5. something else?

I've tried to clarify things in man pages and on web as well. Please have a
look to changes and let us know if it is better or not, and preferably what
can be improved and in which way :-)

The modified deployment page is here:
http://www.freeipa.org/page/Deployment_Recommendations

Man page changes and changes in description of installer options are here:
https://github.com/freeipa/freeipa/pull/352

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-dnskeysyncd not starting

[Petr Spacek]

On 19.12.2016 14:07, Rob Verduijn wrote:
> Hello,
> 
> I'm running ipa on centos 7.3 with the latest patches applied.
> 
> It seem to run fine however the ipa-dnskeysyncd keeps failing to start and
> I keep seeing this message in my logs:
> 
> ipa-dnskeysyncd[25663]: ipa : INFO LDAP bind...
> python2[25663]: GSSAPI client step 1
> python2[25663]: GSSAPI client step 1
> ns-slapd[2569]: GSSAPI server step 1
> python2[25663]: GSSAPI client step 1
> ns-slapd[2569]: GSSAPI server step 2
> python2[25663]: GSSAPI client step 2
> ns-slapd[2569]: GSSAPI server step 3
> ipa-dnskeysyncd[25663]: ipa : INFO Commencing sync process
> ipa-dnskeysyncd[25663]: ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO
> Initial LDAP dump is done, sychronizing with ODS and BIND
> python2[25674]: GSSAPI client step 1
> python2[25674]: GSSAPI client step 1
> ns-slapd[2569]: GSSAPI server step 1
> python2[25674]: GSSAPI client step 1
> ns-slapd[2569]: GSSAPI server step 2
> python2[25674]: GSSAPI client step 2
> ns-slapd[2569]: GSSAPI server step 3
> ipa-dnskeysyncd[25663]: Traceback (most recent call last):
> ipa-dnskeysyncd[25663]: File "/usr/libexec/ipa/ipa-dnskeysyncd", line 110,
> in 
> ipa-dnskeysyncd[25663]: while ldap_connection.syncrepl_poll(all=1,
> msgid=ldap_search):
> ipa-dnskeysyncd[25663]: File
> "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 405, in
> syncrepl_poll
> ipa-dnskeysyncd[25663]: self.syncrepl_refreshdone()
> ipa-dnskeysyncd[25663]: File
> "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", line 115,
> in syncrepl_refreshdone
> ipa-dnskeysyncd[25663]: self.hsm_replica_sync()
> ipa-dnskeysyncd[25663]: File
> "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", line 181,
> in hsm_replica_sync
> ipa-dnskeysyncd[25663]: ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA])
> ipa-dnskeysyncd[25663]: File
> "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 494, in run
> ipa-dnskeysyncd[25663]: raise CalledProcessError(p.returncode, arg_string,
> str(output))
> ipa-dnskeysyncd[25663]: subprocess.CalledProcessError: Command
> '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero exit status 1
> systemd[1]: ipa-dnskeysyncd.service: main process exited, code=exited,
> status=1/FAILURE
> systemd[1]: Unit ipa-dnskeysyncd.service entered failed state.
> systemd[1]: ipa-dnskeysyncd.service failed.
> 
> for some reason the ipa-dnskeysyncd keeops crashing.
> Anybody know where to start looking for this one ?

Please raise the debug level so we can see something in the logs:

http://www.freeipa.org/page/Troubleshooting#ipa_command_crashes_or_returns_no_data

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Kerberos realm for different domain

[Petr Spacek]

On 10.12.2016 19:20, Alexander Bokovoy wrote:
> On la, 10 joulu 2016, William Muriithi wrote:
>> Stephen
>>>
>>> Can you have a domain that belongs to a Kerberos realm with a completely
>>> different domain? For example, could example.com belong to the
>>> ANOTHERDOMAIN.COM realm as long as we control DNS for both and have all the
>>> necessary SRV and TXT records to locate it and krb5.conf is configured
>>> properly?
>>
>> This will indeed work.  Its however highly discouraged by FreeIPA.
> No, it is not.
> 
>> For example, if you do go this way, you will never be able to
>> establish trust relationship with Active directory as Active directory
>> will not accept this setup.
> This is not true at all.
> 
>> Also, you will be on untested territory.  I don't think may people use
>> this setup, so the code may not be well exercised in such a setup.  On
>> the positive side, you could help FreeIPA project flash out any bug
>> that such a setup may expose.
> No, this is very well charted territory. Read a number of threads we had
> just last week and before, last few months.
> 
> In short, the situation Stephen asks an advice on is a very normal case.

Let me clear up this confusion:
The important thing is to have Kerberos REALM = uppercase version of DNS
domain containing all the SRV records (let's call this DNS domain "primary"
DNS domain).

If this condition is fulfilled, AD trusts and other auto-detection procedures
will work. You can add arbitrary number of FreeIPA clients to "secondary" DNS
domains as long as they do not overlap with AD-managed domains and it will
just work.

Does it clear the confusion?

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Naming a FreeIPA domain and router differences

[Petr Spacek]

On 8.12.2016 22:40, Harry Kashouli wrote:
> Ah, I think I totally misread the DNS page, the first time...
> https://www.freeipa.org/page/DNS
> 
> 
> Looks like I should put the router on int.custom.com as a domain, and I can
> create the freeipa domain as domain.custom.com

It depends on you how you want to name the machines. FreeIPA does not care as
long as requirements in the DNS page are met.

Meeting the requirements is significantly easier when you use actual names you
own as it mitigates risk of name collisions.

If you have some specific question do not hesitate to ask.
Petr^2 Spacek


> 
> -Harry
> 
> On 8 December 2016 at 13:15, Harry Kashouli  wrote:
> 
>> Hi all,
>>
>> I want to make sure I'm understanding how to name my FreeIPA server.
>>
>> (following names are placeholders)
>> On my router, I've set the domain to localdomain, so my server
>> automatically gets the full name as server.localdomain. I want my FreeIPA
>> domain to be domain.custom.com because I own the custom.com domain; so
>> when I'm setting it up, I answer the "server host name" question as
>> pc.domain.custom.com.
>>
>> Is this wrong? Does the domain on my router have to match the FreeIPA
>> domain in any way?
>>
>> Thanks,
>> -Harry
>>
> 
> 
> 


-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain.

[Petr Spacek]

On 7.12.2016 14:57, Brian Candler wrote:
> On 07/12/2016 08:58, freeIPA users list wrote:
>> On ke, 07 joulu 2016, List dedicated to discussions about use, configuration
>> and deployment of the IPA server. wrote:
>>> I know the Quick Start Guide and Deployment Recommendations cover this in
>>> depth, but there are still some ambiguities.
>>>
>>> I'm trying to figure out if a company like us, lautus.net should use a DNS
>>> subdomain like ipa.lautus.net for the IPA domain, or not.
>> It is really depending on your deployment details.
>>
>> If you already have some other Kerberized environment in place and you
>> are not going to replace it by FreeIPA, then you need to make sure that
>> new FreeIPA deployment would not conflict with the existing one.
> Or if you think there's a chance you might want to add another Kerberized
> environment later (e.g. "ad.lautus.net")
> 
>>
>>> should continue to be hosted by DNS servers elsewhere that delegate say,
>>> ipa.lautus.net to FreeIPA.
> The question of whether you host ipa.lautus.net DNS (or indeed lautus.net DNS)
> in FreeIPA is a different issue.
> 
> If you're happy with your existing DNS infrastructure, then you can either
> delegate ipa.lautus.net to your FreeIPA servers (with NS records); or run
> FreeIPA without DNS, and simply import the ipa.lautus.net SRV records directly
> into the lautus.net domain.
> 
> Having FreeIPA host the ipa.lautus.net domain means these SRV records are
> populated automatically, but it's not really that hard to add them to an
> existing DNS service.
> 
> OTOH, if you *don't* already have a good authoritative internal DNS service
> with a UI that you like, then you might want to use FreeIPA for this anyway.
> You can easily create extra zones in FreeIPA.
> 
> I would be a bit wary about putting FreeIPA servers out on the public Internet
> though. For one thing, the default config is an open resolver (which you can
> tighten easily enough). I also have a deep distrust of Java, but maybe that's
> just me.

Speaking of DNS, it is just BIND. Configure it accordingly and you should be 
find.

Please note that FreeIPA DNS is not intended as general-purpose DNS:
http://www.freeipa.org/page/DNS#Initial_Considerations

It is tailored for FreeIPA use-cases and might lack special features.


>>> But on the other hand the same doc is full of examples where a Kerberos
>>> realm like EXAMPLE.COM (instead of IPA.EXAMPLE.COM) is used, i.e example
>>> 2.2. of secion 2.3.4. But the same guide also says that the Kerberos realm
>>> should be the same as the ipa DNS domain, just uppercased. So example 2.2.
>>> implies that example.com is running their DNS domain on FreeIPA, for
>>> everything, not just for IPA SRV and TXT entries.
> The Kerberos realm always has a corresponding DNS domain, so realm
> IPA.LAUTUS.NET has a corresponding DNS domain "ipa.lautus.net".
> 
> But with FreeIPA you can still manage hosts called foo.lautus.net or
> bar.int.lautus.net. At worst you'd have some extra [domain_realm] mappings in
> krb5.conf

Yes. Ideally you will be able to add _kerberos TXT records to relevant DNS
domains so explicit mapping will not be necessary.

I will have a look how we can clarify the guide to make this less confusing...

> 
> (Aside: Active Directory is much more fussy, and basically doesn't work if the
> hosts don't have hostnames within the same DNS domain as their kerberos realm
> - and indeed have reverse DNS as well as forward)
> 
>>
>>> And when ipa-client-install is run on somehost.lautus.net, it also defaults
>>> to LAUTUS.NET for Kerberos domain, as if the default expectation is that
>>> your toplevel company DNS name would be your kerberos domain.
> But you can override that.
> 
>>
>>
>>> And when I install a trial IPA server on host ipa-server-1.lautus.net using
>>> "ipa-server-install --setup-dns --realm IPA.LAUTUS.NET --domain
>>> ipa.lautus.net --forwarder=8.8.8.8", and then look at the DNS Zones  in the
>>> Web UI, I see not only ipa.lautus.net, but also lautus, with record "@ NS
>>> ipa-server-1.lautus.net". In other words the IPA server defaults to
>>> thinking it owns the domain above ipa.lautus.net too. Which goes against
>>> 2.3.1 above.
> Interesting. What does "ipa dnszone-find --pkey-only" show?
> 
> It seems like it's created an authoritative zone both for the server's own
> domain (lautus.net if the server is xxx.lautus.net) as well as the realm's
> domain (ipa.lautus.net)
> 
> I don't know why it's doing that. Now I've checked with another system here:
> the hostname is "ipa-1.int.example.com" and the realm is "ipa.example.com",
> and you're right, it is authoritative for both:
> 
>   Zone name: int.example.com.
>   Zone name: ipa.example.com.
> 
> This isn't what I wanted. The int.example.com domain is hosted externally and
> I didn't want to override it. Right now it's hiding all names in
> int.example.com that it doesn't know about.
> 
> I would expect that it's possible to remove this zone, but I'd need to 

Re: [Freeipa-users] Freeipa on ARM (raspberry pi) - OpenJDK vs. Oracle JDK

[Petr Spacek]

On 1.12.2016 09:07, Winfried de Heiden wrote:
> Hi all,
> 
> Started as "just because it's possible" running FreeIPA on a BananaPI or 
> Raspberry PI turned to out to be rather succesfull and for more than a year I 
> use FreeIPA at home.
> 
> OK, running on small boards like Raspberry PI it never will be fast but it's 
> surely quick enough to run at small scale. However, starting FreeIPA became 
> much 
> slower since Fedora 24 and even more on Fedora 25.
> Since Oracle Java is also available for ARM and there's much written this is 
> much faster I took some time for an experiment.
> 
> Starting FreeIPA using the default installation (running OpenJDK) starting 
> FreeIPA takes a painfull 15 minutes (afterward, it all just works fine):
> 
> [root@rpi2 sysconfig]# time ipactl start
> Starting Directory Service
> Starting krb5kdc Service
> Starting kadmin Service
> Starting named Service
> Starting ipa_memcached Service
> Starting httpd Service
> Starting ipa-custodia Service
> Starting ntpd Service
> Starting pki-tomcatd Service
> Starting ipa-otpd Service
> Starting ipa-dnskeysyncd Service
> ipa: INFO: The ipactl command was successful
> 
> real15m40.638s
> user0m33.095s
> sys0m1.910s
> 
> Now, after installing Oracle Java and changing JAVA_HOME in 
> /etc/sysconfig/pki-tomcat to:
> 
> #JAVA_HOME="/usr/lib/jvm/jre-1.8.0-openjdk"
> JAVA_HOME="/opt/jdk1.8.0_111/jre"
> 
> [root@rpi2 sysconfig]# time ipactl start
> Starting Directory Service
> Starting krb5kdc Service
> Starting kadmin Service
> Starting named Service
> Starting ipa_memcached Service
> Starting httpd Service
> Starting ipa-custodia Service
> Starting ntpd Service
> Starting pki-tomcatd Service
> Starting ipa-otpd Service
> Starting ipa-dnskeysyncd Service
> ipa: INFO: The ipactl command was successful
> 
> real2m14.823s
> user0m33.400s
> sys0m1.730s
> 
> Wow, I expected some improvement, but this far better than expected! This 
> leaves 
> a question: what is happening here!!??

Huh? That is really huge difference. Please open a bug against OpenJDK:
https://bugzilla.redhat.com/enter_bug.cgi

That way it will reach OpenJDK developers. They will have better idea than
FreeIPA developers, I guess.

Please report the bug number to this forum so we can track it as well.

Thank you very much!
Petr^2 Spacek

> 
> I prefer to use OpenJDK, it 's Open Source and because it's availabe from the 
> Fedora ARM repositories it is also much more easy to update. But for now, 
> Oracle 
> is much faster and OpenJDK from this point of view is a very poor alternative.
> Why is OpenJDK so much slower? Is improvement possible? For now (some 
> "tweaking") of in a future release?
> 
> For the record, I tested these Java versions:
> 
> [root@rpi2 sysconfig]# 
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-3.b16.fc25.arm/jre/bin/java -version
> openjdk version "1.8.0_111"
> OpenJDK Runtime Environment (build 1.8.0_111-b16)
> OpenJDK Zero VM (build 25.111-b16, interpreted mode)
> 
> [root@rpi2 sysconfig]# /opt/jdk1.8.0_111/jre/bin/java -version
> java version "1.8.0_111"
> Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
> Java HotSpot(TM) Client VM (build 25.111-b14, mixed mode)
> 
> 
> Kind regards,
> 
> Winfried
> 
> 
> 


-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Ping forwarded domain name.

[Petr Spacek]

On 25.11.2016 14:48, TomK wrote:
> On 11/25/2016 4:00 AM, Petr Spacek wrote:
>> On 25.11.2016 05:57, TomK wrote:
>>> On 11/24/2016 4:49 AM, Petr Spacek wrote:
>>>> On 24.11.2016 06:08, TomK wrote:
>>>>> On 11/23/2016 3:28 AM, Martin Basti wrote:
>>>>>>
>>>>>>
>>>>>> On 23.11.2016 03:48, TomK wrote:
>>>>>>> On 11/22/2016 10:22 AM, Martin Basti wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 22.11.2016 13:57, TomK wrote:
>>>>>>>>> On 11/22/2016 2:59 AM, Martin Basti wrote:
>>>>>>>>>> Hey,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 22.11.2016 06:33, TomK wrote:
>>>>>>>>>>> Hey Guy's,
>>>>>>>>>>>
>>>>>>>>>>> I'm forwarding a domain dom.abc.xyz from a Windows Server 2012
>>>>>>>>>>> over to
>>>>>>>>>>> my dual Free IPA server.  The Free IPA servers are authoritative for
>>>>>>>>>>> this subdomain.  The Windows Server 2012 DNS is resolves on abc.xyz
>>>>>>>>>>> and forwards dom.abc.xyz.
>>>>>>>>>> Do you have configured proper zone delegation for subdomain
>>>>>>>>>> dom.abc.xyz?
>>>>>>>>>> Proper NS and glue records
>>>>>>>>>> http://www.zytrax.com/books/dns/ch9/delegate.html
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I cannot ping dom.abc.xyz.  Everything else, including client
>>>>>>>>>>> registrations, work fine.  If Free IPA is authoritative on
>>>>>>>>>>> dom.abc.xyz, should it not create DNS entries so the sub domain
>>>>>>>>>>> can be
>>>>>>>>>>> pinged as well?
>>>>>>>>>>
>>>>>>>>>> What do you mean by "ping"?
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> /etc/resolv.conf also get's regenerated on reboot on the IPA Servers
>>>>>>>>>>> and wanted to ask if you can point me to some materials online to
>>>>>>>>>>> determine where can I permanently adjust the search to add
>>>>>>>>>>> dom.abc.xyz
>>>>>>>>>>> to the already present abc.xyz .  I wasn't able to locate what I
>>>>>>>>>>> needed in my searches.
>>>>>>>>>>>
>>>>>>>>>>> I'm using the latest v4.
>>>>>>>>>>
>>>>>>>>>> It depends on what are you using, probably you have NetworkManager
>>>>>>>>>> there
>>>>>>>>>> that is editing /etc/resolv.conf
>>>>>>>>>>
>>>>>>>>>> https://ask.fedoraproject.org/en/question/67752/how-do-i-add-a-search-domain-using-networkmanager/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Martin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I Uninstalled NetworkManager.  Still changes.
>>>>>>>>> ping dom.abc.com results in "ping: unknown host"
>>>>>>>>>
>>>>>>>>> I'll have a look at the first link, ty.
>>>>>>>>>
>>>>>>>>
>>>>>>>> ping (ICMP protocol) and DNS system are different things, do you have
>>>>>>>> hostname dom.abc.com with A record or it is a zone?
>>>>>>>>
>>>>>>>> with ping command hostname "dom.abc.com" is resolved to IP address
>>>>>>>> first, do you have A record set for dom.abc.com in zone apex or what 
>>>>>>>> are
>>>>>>>> you trying to achieve with ping command?
>>>>>>>>
>>>>>>>>

Re: [Freeipa-users] Ping forwarded domain name.

[Petr Spacek]

On 25.11.2016 05:57, TomK wrote:
> On 11/24/2016 4:49 AM, Petr Spacek wrote:
>> On 24.11.2016 06:08, TomK wrote:
>>> On 11/23/2016 3:28 AM, Martin Basti wrote:
>>>>
>>>>
>>>> On 23.11.2016 03:48, TomK wrote:
>>>>> On 11/22/2016 10:22 AM, Martin Basti wrote:
>>>>>>
>>>>>>
>>>>>> On 22.11.2016 13:57, TomK wrote:
>>>>>>> On 11/22/2016 2:59 AM, Martin Basti wrote:
>>>>>>>> Hey,
>>>>>>>>
>>>>>>>>
>>>>>>>> On 22.11.2016 06:33, TomK wrote:
>>>>>>>>> Hey Guy's,
>>>>>>>>>
>>>>>>>>> I'm forwarding a domain dom.abc.xyz from a Windows Server 2012
>>>>>>>>> over to
>>>>>>>>> my dual Free IPA server.  The Free IPA servers are authoritative for
>>>>>>>>> this subdomain.  The Windows Server 2012 DNS is resolves on abc.xyz
>>>>>>>>> and forwards dom.abc.xyz.
>>>>>>>> Do you have configured proper zone delegation for subdomain
>>>>>>>> dom.abc.xyz?
>>>>>>>> Proper NS and glue records
>>>>>>>> http://www.zytrax.com/books/dns/ch9/delegate.html
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I cannot ping dom.abc.xyz.  Everything else, including client
>>>>>>>>> registrations, work fine.  If Free IPA is authoritative on
>>>>>>>>> dom.abc.xyz, should it not create DNS entries so the sub domain
>>>>>>>>> can be
>>>>>>>>> pinged as well?
>>>>>>>>
>>>>>>>> What do you mean by "ping"?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> /etc/resolv.conf also get's regenerated on reboot on the IPA Servers
>>>>>>>>> and wanted to ask if you can point me to some materials online to
>>>>>>>>> determine where can I permanently adjust the search to add
>>>>>>>>> dom.abc.xyz
>>>>>>>>> to the already present abc.xyz .  I wasn't able to locate what I
>>>>>>>>> needed in my searches.
>>>>>>>>>
>>>>>>>>> I'm using the latest v4.
>>>>>>>>
>>>>>>>> It depends on what are you using, probably you have NetworkManager
>>>>>>>> there
>>>>>>>> that is editing /etc/resolv.conf
>>>>>>>>
>>>>>>>> https://ask.fedoraproject.org/en/question/67752/how-do-i-add-a-search-domain-using-networkmanager/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Martin
>>>>>>>
>>>>>>>
>>>>>>> I Uninstalled NetworkManager.  Still changes.
>>>>>>> ping dom.abc.com results in "ping: unknown host"
>>>>>>>
>>>>>>> I'll have a look at the first link, ty.
>>>>>>>
>>>>>>
>>>>>> ping (ICMP protocol) and DNS system are different things, do you have
>>>>>> hostname dom.abc.com with A record or it is a zone?
>>>>>>
>>>>>> with ping command hostname "dom.abc.com" is resolved to IP address
>>>>>> first, do you have A record set for dom.abc.com in zone apex or what are
>>>>>> you trying to achieve with ping command?
>>>>>>
>>>>>> for testing DNS try to use commands: dig, host, nslookup
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>
>>>>> Apologize for the long reply but it should give some background on
>>>>> what it is that I'm doing.
>>>>>
>>>>> 1) dom.abc.com is a zone.  There is no A record for dom.abc.com in
>>>>> FreeIPA (Confirmed by Petr).  I get the point Petr Spacek pointed out
>>>>> in his comment as well.  What should it really point too? ( I kind of
>>>>> answer this question below so please read on. )  Where I'm getting
>>>>> this from is that in Windows Server 2012 abc.com retu

Re: [Freeipa-users] Ping forwarded domain name.

[Petr Spacek]

On 24.11.2016 06:08, TomK wrote:
> On 11/23/2016 3:28 AM, Martin Basti wrote:
>>
>>
>> On 23.11.2016 03:48, TomK wrote:
>>> On 11/22/2016 10:22 AM, Martin Basti wrote:
>>>>
>>>>
>>>> On 22.11.2016 13:57, TomK wrote:
>>>>> On 11/22/2016 2:59 AM, Martin Basti wrote:
>>>>>> Hey,
>>>>>>
>>>>>>
>>>>>> On 22.11.2016 06:33, TomK wrote:
>>>>>>> Hey Guy's,
>>>>>>>
>>>>>>> I'm forwarding a domain dom.abc.xyz from a Windows Server 2012
>>>>>>> over to
>>>>>>> my dual Free IPA server.  The Free IPA servers are authoritative for
>>>>>>> this subdomain.  The Windows Server 2012 DNS is resolves on abc.xyz
>>>>>>> and forwards dom.abc.xyz.
>>>>>> Do you have configured proper zone delegation for subdomain
>>>>>> dom.abc.xyz?
>>>>>> Proper NS and glue records
>>>>>> http://www.zytrax.com/books/dns/ch9/delegate.html
>>>>>>
>>>>>>>
>>>>>>> I cannot ping dom.abc.xyz.  Everything else, including client
>>>>>>> registrations, work fine.  If Free IPA is authoritative on
>>>>>>> dom.abc.xyz, should it not create DNS entries so the sub domain
>>>>>>> can be
>>>>>>> pinged as well?
>>>>>>
>>>>>> What do you mean by "ping"?
>>>>>>
>>>>>>>
>>>>>>> /etc/resolv.conf also get's regenerated on reboot on the IPA Servers
>>>>>>> and wanted to ask if you can point me to some materials online to
>>>>>>> determine where can I permanently adjust the search to add
>>>>>>> dom.abc.xyz
>>>>>>> to the already present abc.xyz .  I wasn't able to locate what I
>>>>>>> needed in my searches.
>>>>>>>
>>>>>>> I'm using the latest v4.
>>>>>>
>>>>>> It depends on what are you using, probably you have NetworkManager
>>>>>> there
>>>>>> that is editing /etc/resolv.conf
>>>>>>
>>>>>> https://ask.fedoraproject.org/en/question/67752/how-do-i-add-a-search-domain-using-networkmanager/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Martin
>>>>>
>>>>>
>>>>> I Uninstalled NetworkManager.  Still changes.
>>>>> ping dom.abc.com results in "ping: unknown host"
>>>>>
>>>>> I'll have a look at the first link, ty.
>>>>>
>>>>
>>>> ping (ICMP protocol) and DNS system are different things, do you have
>>>> hostname dom.abc.com with A record or it is a zone?
>>>>
>>>> with ping command hostname "dom.abc.com" is resolved to IP address
>>>> first, do you have A record set for dom.abc.com in zone apex or what are
>>>> you trying to achieve with ping command?
>>>>
>>>> for testing DNS try to use commands: dig, host, nslookup
>>>>
>>>> Martin
>>>>
>>>
>>> Apologize for the long reply but it should give some background on
>>> what it is that I'm doing.
>>>
>>> 1) dom.abc.com is a zone.  There is no A record for dom.abc.com in
>>> FreeIPA (Confirmed by Petr).  I get the point Petr Spacek pointed out
>>> in his comment as well.  What should it really point too? ( I kind of
>>> answer this question below so please read on. )  Where I'm getting
>>> this from is that in Windows Server 2012 abc.com returns the IP of any
>>> of the participating AD / DNS servers within the cluster (The two
>>> Windows Server 2012 are a combined clustered AD + DNS servers.).
>>> Being able to resolve abc.xyz is handy.  During a lookup, I can get a
>>> list of all the IP's associated with that domain which would indicate
>>> all the DNS + AD servers online under that domain or serving that domain:
>>>
>>>
>>> # nslookup abc.xyz
>>> Server: 192.168.0.3
>>> Address:192.168.0.3#53
>>>
>>> Name:   abc.xyz
>>> Address: 192.168.0.3
>>> Name:   abc.xyz
>>> Address: 192.168.0.1
>>> Name:   abc.xyz
>>> Address: 192.168.0.2
>>> #
&

Re: [Freeipa-users] Ping forwarded domain name.

[Petr Spacek]

On 22.11.2016 13:57, TomK wrote:
> On 11/22/2016 2:59 AM, Martin Basti wrote:
>> Hey,
>>
>>
>> On 22.11.2016 06:33, TomK wrote:
>>> Hey Guy's,
>>>
>>> I'm forwarding a domain dom.abc.xyz from a Windows Server 2012 over to
>>> my dual Free IPA server.  The Free IPA servers are authoritative for
>>> this subdomain.  The Windows Server 2012 DNS is resolves on abc.xyz
>>> and forwards dom.abc.xyz.
>> Do you have configured proper zone delegation for subdomain dom.abc.xyz?
>> Proper NS and glue records
>> http://www.zytrax.com/books/dns/ch9/delegate.html
>>
>>>
>>> I cannot ping dom.abc.xyz.  Everything else, including client
>>> registrations, work fine.  If Free IPA is authoritative  on
>>> dom.abc.xyz, should it not create DNS entries so the sub domain can be
>>> pinged as well?
>>
>> What do you mean by "ping"?
>>
>>>
>>> /etc/resolv.conf also get's regenerated on reboot on the IPA Servers
>>> and wanted to ask if you can point me to some materials online to
>>> determine where can I permanently adjust the search to add dom.abc.xyz
>>> to the already present abc.xyz .  I wasn't able to locate what I
>>> needed in my searches.
>>>
>>> I'm using the latest v4.
>>
>> It depends on what are you using, probably you have NetworkManager there
>> that is editing /etc/resolv.conf
>>
>> https://ask.fedoraproject.org/en/question/67752/how-do-i-add-a-search-domain-using-networkmanager/
>>
>>
>>
>> Martin
> 
> 
> I Uninstalled NetworkManager.  Still changes.
> ping dom.abc.com results in "ping: unknown host"

FreeIPA does not put any IP address (A/) record onto its domain name by
default. (The philosophical question would be - what IP address should go 
there?)

If you want to ping something, ping one of your FreeIPA servers.

If want to test DNS, use a DNS tool like dig or so to test if names from that
domain can be resolved.

Petr^2 Spacek

> I'll have a look at the first link, ty.

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] keytab kvno differs between ipa servers

[Petr Spacek]

On 21.11.2016 13:29, Bjarne Blichfeldt wrote:
> IPA: VERSION: 4.4.0, API_VERSION: 2.213
> 
> This may be for lack of understanding the process, but..
> 
> When I retrieve a keytab for a principal using ipa-getkeytab, the kvno is 
> increased on the idm.
> In our test environment we have two ipa servers running and the kvno is only 
> increased on one of them. After several retrivals, one principals kvno is now 
> on 5 on ipa1 and 18 on ipa2.
> 
> That means the resulting keytab is only usable on one ipa server and results 
> in a "password expired" message from the other ipa server.
> 
> How do I synchronize the two Kerberos servers and how do I avoid this?

This might be caused by broken replication between your IPA servers:
http://www.freeipa.org/page/Troubleshooting#Replication_issues

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] minimise impact compromised host

[Petr Spacek]

On 16.11.2016 18:26, Stijn De Weirdt wrote:
> hi petr,
> 
> this is a different question: what can we do such that compromised host
> can do a little as possible if the admin doesn't (yet) know the host is
> compromised.
>
> the default policy allows way too much.

 For any useful advice we need more details.

 What are the operations you want to disable?
>>> at the very least, "kvno userlogin" should fail (i.e. access to a host
>>> keytab shouldn't permit retrieval of arbitrary user token).
>>
>> I think that this is misunderstanding.
> i'll spend some more time rereading and getting a better understanding
> (again ;)
> 
>>
>> "kvno userlogin" does not allow the attacker to do anything. The result of
>> kvno command is a service ticket for particular principal (user, host).
>>
>> The attacker can use this service ticket *for authentication to the 
>> particular
>> principal* (user, host).
>>
>> So the only thing the attacker can do is to prove its identity to given 
>> (user,
>> host). This exactly matches capabilities the attacker already has - the full
>> control over the host.
> hhmm, ok. is there a way to let e.g. klist show this? it now says
> 'userlogin@REALM' in the 'Service principal' column. for the (user,host)
> combo i expected to see a userlogin/fqdn@REALM, like other service tokens.
> 
> anyway, clearly i'm missing something here.

The important field is 'Default principal:' which is above the list of
tickets. It contains name of the principal "who you are".

Rest of the list shows just service tickets which are used to authenticate you
to the services listed in the list. It just means that you tried to contact
them some time ago (or called kvno explicitly).

Please go and read some articles about Kerberos protocol, e.g. the Wikipedia
article I linked below. It will explain a lot of things.

Petr^2 Spacek

> 
> 
> stijn
> 
>>
>> Please see
>> https://en.wikipedia.org/wiki/Kerberos_(protocol)#Client_Service_Request
>> for further details on this.
>>
>> Does it explain the situation?
>>
>> Petr^2 Spacek
>>
>>>
>>> i'm assuming that retrieval of service tokens for another host is
>>> already not possible? (ie if you have keyatb of fqdn1, you shouldn't be
>>> able to retrieve a token for SERVICE/fqdn2@REALM).
>>>
>>> stijn
>>>

 Petr^2 Spacek


>
> how to clean it up once you know the host is compromised is the subject
> of the other thread.
>
> stijn
>
>>
>> In the case that the host is compromised/stolen/hijacked, you can
>> host-disable it to invalidate the keytab stored there but this does not
>> prevent anyone logged on that host to bruteforce/DOS user accounts by
>> trying to guess their Kerberos keys by repeated kinit.
>>
>


>>>
>>
>>


-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] minimise impact compromised host

[Petr Spacek]

On 16.11.2016 17:47, Stijn De Weirdt wrote:
>>> this is a different question: what can we do such that compromised host
>>> can do a little as possible if the admin doesn't (yet) know the host is
>>> compromised.
>>>
>>> the default policy allows way too much.
>>
>> For any useful advice we need more details.
>>
>> What are the operations you want to disable?
> at the very least, "kvno userlogin" should fail (i.e. access to a host
> keytab shouldn't permit retrieval of arbitrary user token).

I think that this is misunderstanding.

"kvno userlogin" does not allow the attacker to do anything. The result of
kvno command is a service ticket for particular principal (user, host).

The attacker can use this service ticket *for authentication to the particular
principal* (user, host).

So the only thing the attacker can do is to prove its identity to given (user,
host). This exactly matches capabilities the attacker already has - the full
control over the host.

Please see
https://en.wikipedia.org/wiki/Kerberos_(protocol)#Client_Service_Request
for further details on this.

Does it explain the situation?

Petr^2 Spacek

> 
> i'm assuming that retrieval of service tokens for another host is
> already not possible? (ie if you have keyatb of fqdn1, you shouldn't be
> able to retrieve a token for SERVICE/fqdn2@REALM).
> 
> stijn
> 
>>
>> Petr^2 Spacek
>>
>>
>>>
>>> how to clean it up once you know the host is compromised is the subject
>>> of the other thread.
>>>
>>> stijn
>>>

 In the case that the host is compromised/stolen/hijacked, you can
 host-disable it to invalidate the keytab stored there but this does not
 prevent anyone logged on that host to bruteforce/DOS user accounts by
 trying to guess their Kerberos keys by repeated kinit.

>>>
>>
>>
> 


-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] IPA 4.4 and Trust Agents/Controllers

[Petr Spacek]

On 16.11.2016 16:40, Baird, Josh wrote:
> Hi,
> 
> I'm currently testing an IPA 4.3 (RHEL 7.2) to IPA 4.4 (RHEL 7.3) upgrade and 
> had a few questions about the concept of trust agents/controllers.
> 
> Prior to IPA 4.4, were all IPA masters (that 'ipa-adtrust-install' was ran 
> on)  considered 'trust controllers'?  In my lab, the upgrade automatically 
> provisioned my IPA masters as controllers (not agents).  Is this the default 
> behavior? 

I would recommend to read
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/creating-trusts.html#trust-controller-agent

> The official recommendation appears to be to minimize the number of trust 
> controllers.  Given an IPA deployment with two masters in each location, is 
> the recommendation to only have 1 of these configured as a 'trust controller' 
> and the other as a 'trust agent'?
> 
> What happens if all 'trust controllers' become unavailable, but 'trust 
> agents' remain available?  Will the trust between IPA and AD be broken?

... Trust controllers can be used for trust management operations, such as
adding trust agreements and enabling or disabling separate domains from a
trusted forest to access IdM resources. Additionally, AD domain controllers
contact trust controllers when validating the trust.


If I'm not mistaken, temporary unavailability of trust controller should not
break the trust as it is used only for trust management operations.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] minimise impact compromised host

[Petr Spacek]

On 16.11.2016 15:33, Stijn De Weirdt wrote:
> hi martin,
> 
 we are looking how to configure whatever relevant policy to minimise the
 impact of compromised IPA hosts (ie servers with a valid host keytab).

 in particular, it looks like it possible to retrieve any user token once
 you have access to a valid host keytab.

 we're aware that the default IPA policies are wide open, but we are
 looking how to limit this. for us, there's no need that a hostkeytab can
 retrieve tokens for anything except the services on that host.
>>>
>>> What "token" do you have in mind?
>>>
>> We discussed this in another thread.
> this is a different question: what can we do such that compromised host
> can do a little as possible if the admin doesn't (yet) know the host is
> compromised.
> 
> the default policy allows way too much.

For any useful advice we need more details.

What are the operations you want to disable?

Petr^2 Spacek


> 
> how to clean it up once you know the host is compromised is the subject
> of the other thread.
> 
> stijn
> 
>>
>> In the case that the host is compromised/stolen/hijacked, you can
>> host-disable it to invalidate the keytab stored there but this does not
>> prevent anyone logged on that host to bruteforce/DOS user accounts by
>> trying to guess their Kerberos keys by repeated kinit.
>>
> 


-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Client x.x.xx - RFC 1918 response from Internet in /var/log/messages

[Petr Spacek]

On 16.11.2016 12:56, Bjarne Blichfeldt wrote:
> Just updated a couple of free-ipa servers to:
> ipa-server-dns-4.4.0-12.el7.noarch
> redhat-release-server-7.3-7.el7.x86_64
> 
> Before the update, I resolved the issue with RFC messages by:
> /etc/named.conf:
> options {
>disable-empty-zone "10.in-addr.arpa.";
> :
> 
> Now after the update the RFS messages has returned. I read in the changelog 
> for 4.4 that this issue was resolved.
> What did I miss?

This sort of misconfiguration is described on

https://deepthought.isc.org/article/AA-00204/0/What-does-RFC-1918-response-from-Internet-for-0.0.0.10.IN-ADDR.ARPA-mean.html


Please follow advices on ISC web to fix this. You are most probably sending
your queries to the public Internet instead of your internal network.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] minimise impact compromised host

[Petr Spacek]

On 16.11.2016 14:01, Stijn De Weirdt wrote:
> hi all,
> 
> we are looking how to configure whatever relevant policy to minimise the
> impact of compromised IPA hosts (ie servers with a valid host keytab).
> 
> in particular, it looks like it possible to retrieve any user token once
> you have access to a valid host keytab.
> 
> we're aware that the default IPA policies are wide open, but we are
> looking how to limit this. for us, there's no need that a hostkeytab can
> retrieve tokens for anything except the services on that host.

What "token" do you have in mind?

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] SRV (mixed?) records

[Petr Spacek]

On 10.11.2016 12:08, lejeczek wrote:
> 
> 
> On 10/11/16 10:44, Petr Spacek wrote:
>> This is non-standard situation so it asks for non-standard commands.
>>
>> I would try:
>> $ ipa privilege-mod 'DNS Servers'
>> --addattr=member=krbprincipalname=DNS/rider..xx.xx..xx.x...@.xx.xx..xx.xx.x,cn=services,cn=xxcounts,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x'
>>
>> $ ipa privilege-mod 'DNS Servers'
>> --addattr=member=krbprincipalname=ipa-dnskeysyncd/rider..xx.xx..xx.x...@.xx.xx..xx.xx.x,cn=services,cn=xxcounts,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x'
>>
>>
>> Be very careful when constructing these DNs, --addattr do not validate the
>> input!
> 
> well, I realize these can be trivial trifles, but man, you saved the... week!
> And to finish (hopefully) - maybe even more of a puzzle: how it happened?
> This box member was fine, suddenly (I was recovering/reconnecting replication
> agreements), maybe not suddenly, but when I noticed at some point, it did
> that. It lost those ldap bits?

Good question! I really do not know. You may dig into /var/log/dirsrv/* and
look for modifications in the privilege LDAP entry but that is the only advice
I have.

Please let us know if you found out how it happened.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] SRV (mixed?) records

[Petr Spacek]

On 10.11.2016 11:32, lejeczek wrote:
> 
> 
> On 10/11/16 06:51, Petr Spacek wrote:
>> On 9.11.2016 16:57, lejeczek wrote:
>>>
>>> On 09/11/16 14:35, Martin Basti wrote:
>>>>
>>>> On 09.11.2016 15:33, lejeczek wrote:
>>>>>
>>>>> On 09/11/16 13:48, Martin Basti wrote:
>>>>>>
>>>>>> On 09.11.2016 14:11, lejeczek wrote:
>>>>>>>
>>>>>>> On 09/11/16 12:43, Martin Basti wrote:
>>>>>>>>
>>>>>>>> On 09.11.2016 12:15, lejeczek wrote:
>>>>>>>>>
>>>>>>>>> On 08/11/16 19:37, Martin Basti wrote:
>>>>>>>>>>
>>>>>>>>>> On 08.11.2016 19:41, lejeczek wrote:
>>>>>>>>>>> hi everyone
>>>>>>>>>>> when I look at my domain I see something which seems inconsistent to
>>>>>>>>>>> me (eg. work5 is not part of the domain, was --uninstalled)
>>>>>>>>>>> Do these record need fixing?
>>>>>>>>>>> I'm asking becuase one of the servers, despite the fact the ipa dns
>>>>>>>>>>> related toolkit(on that server) shows zone & records, to
>>>>>>>>>>> dig/host/etc. presents nothing, empty responses!??
>>>>>>>>>>>
>>>>>>>>>>> $ ipa dnsrecord-find xx.xx.xx.xx.x.
>>>>>>>>>>>Record name: @
>>>>>>>>>>>NS record: swir.xx.xx.xx.xx.x., rider.xx.xx.xx.xx.x.,
>>>>>>>>>>>   dzien.xx.xx.xx.xx.x., whale.xx.xx.xx.xx.x.
>>>>>>>>>>>
>>>>>>>>>>>Record name: _kerberos
>>>>>>>>>>>TXT record: .xx.xx..xx.xx.x
>>>>>>>>>>>
>>>>>>>>>>>Record name:
>>>>>>>>>>> _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs
>>>>>>>>>>>SRV record: 0 100 88 rider, 0 100 88 work5
>>>>>>>>>>>
>>>>>>>>>>>Record name: _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs
>>>>>>>>>>>SRV record: 0 100 389 rider, 0 100 389 work5
>>>>>>>>>>>
>>>>>>>>>>>Record name:
>>>>>>>>>>> _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs
>>>>>>>>>>>SRV record: 0 100 88 rider, 0 100 88 work5
>>>>>>>>>>>
>>>>>>>>>>>Record name: _kerberos._tcp.dc._msdcs
>>>>>>>>>>>SRV record: 0 100 88 rider, 0 100 88 work5
>>>>>>>>>>>
>>>>>>>>>>>Record name: _ldap._tcp.dc._msdcs
>>>>>>>>>>>SRV record: 0 100 389 rider, 0 100 389 work5
>>>>>>>>>>>
>>>>>>>>>>>Record name: _kerberos._udp.dc._msdcs
>>>>>>>>>>>SRV record: 0 100 88 rider, 0 100 88 work5
>>>>>>>>>>>
>>>>>>>>>>>Record name: _kerberos._tcp
>>>>>>>>>>>SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100
>>>>>>>>>>> 88 swir
>>>>>>>>>>>
>>>>>>>>>>>Record name: _kerberos-master._tcp
>>>>>>>>>>>SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100
>>>>>>>>>>> 88 swir
>>>>>>>>>>>
>>>>>>>>>>>Record name: _kpasswd._tcp
>>>>>>>>>>>SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 464 dzien, 0 
>>>>>>>>>>> 100
>>>>>>>>>>> 464 whale
>>>>>>>>>>>
>>>>>>>>>>>Record name: _ldap._tcp
>>>>>>>>>>>SRV record: 0 100 389 swir, 0 100 389 dzien, 0 100 389 whale, 0 
>>>>>>>>>>> 100
>>>>>>>>>>> 389 rider
>>>>>>>>>>>
>>>>>>>>>>>Record name:

Re: [Freeipa-users] bind-dyndb-ldap and replication requirements

[Petr Spacek]

On 10.11.2016 06:43, David Kupka wrote:
> On 10/11/16 01:14, Brendan Kearney wrote:
>> i am asking this for a friend who is trying to figure out how to get
>> bind-dyndb-ldap working against openldap on ubuntu.  she does not have
>> replication between two or more ldap instances, and needs to figure out
>> the minimum requirements for bind-dyndb-ldap.  i have been trying to
>> help her, but i am unsure about what is needed, as i have n-way multi
>> master replication working already.
>>
>> can anyone provide what the replication requirements are for
>> bind-dyndb-ldap?  currently, the SyncRepl module is loaded and the
>> overlay is created and configured for the mdb.  i have tried to help get
>> olcServerID and olcMirrorMode set in cn=config and
>> olcDatabase={2}mdb,cn=config respectively, but some errors were
>> encountered there.  is there a best practices doc that we can review?
>>
>> the environment, as best i can tell is ubuntu, openldap 2.4.42 and bind
>> 9.  exact os and bind versions are not known right now.
>>
>> thanks,
>>
>> brendan kearney
>>
> 
> Hello Brendan,
> I don't have any experience with running OpenLDAP + bind-dyndb-ldap but quick
> web search showed me this:
> 
> https://blogs.mindspew-age.com/2013/06/07/bind-dns-openldap-mdb-dynamic-domainsub-domain-configuration-of-dns/
> 
> 
> The article is about CentOS 6 and more than 3 years old but still might be
> helpful because it's mainly about Bind 9 configuration.

This article is not applicable to new versions of bind-dyndb-ldap, the new
versions require SyncRepl.

Any OpenLDAP article about setting SyncRepl provider will suffice,
bind-dyndb-ldap does not require anything special on OpenLDAP side.

You can use following command to test if SyncRepl works and access control is
correct:

$ ldapsearch -h ldap.example.com -D "uid=bind-user,cn=users,${BASE}" -w
root4lab -E sync=rp -b "cn=dns,${BASE}"
'(|(objectClass=idnsConfigObject)(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))'

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] SRV (mixed?) records

[Petr Spacek]

On 9.11.2016 16:57, lejeczek wrote:
> 
> 
> On 09/11/16 14:35, Martin Basti wrote:
>>
>>
>> On 09.11.2016 15:33, lejeczek wrote:
>>>
>>>
>>> On 09/11/16 13:48, Martin Basti wrote:


 On 09.11.2016 14:11, lejeczek wrote:
>
>
> On 09/11/16 12:43, Martin Basti wrote:
>>
>>
>> On 09.11.2016 12:15, lejeczek wrote:
>>>
>>>
>>> On 08/11/16 19:37, Martin Basti wrote:


 On 08.11.2016 19:41, lejeczek wrote:
> hi everyone
> when I look at my domain I see something which seems inconsistent to
> me (eg. work5 is not part of the domain, was --uninstalled)
> Do these record need fixing?
> I'm asking becuase one of the servers, despite the fact the ipa dns
> related toolkit(on that server) shows zone & records, to
> dig/host/etc. presents nothing, empty responses!??
>
> $ ipa dnsrecord-find xx.xx.xx.xx.x.
>   Record name: @
>   NS record: swir.xx.xx.xx.xx.x., rider.xx.xx.xx.xx.x.,
>  dzien.xx.xx.xx.xx.x., whale.xx.xx.xx.xx.x.
>
>   Record name: _kerberos
>   TXT record: .xx.xx..xx.xx.x
>
>   Record name: _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs
>   SRV record: 0 100 88 rider, 0 100 88 work5
>
>   Record name: _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs
>   SRV record: 0 100 389 rider, 0 100 389 work5
>
>   Record name: _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs
>   SRV record: 0 100 88 rider, 0 100 88 work5
>
>   Record name: _kerberos._tcp.dc._msdcs
>   SRV record: 0 100 88 rider, 0 100 88 work5
>
>   Record name: _ldap._tcp.dc._msdcs
>   SRV record: 0 100 389 rider, 0 100 389 work5
>
>   Record name: _kerberos._udp.dc._msdcs
>   SRV record: 0 100 88 rider, 0 100 88 work5
>
>   Record name: _kerberos._tcp
>   SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100
> 88 swir
>
>   Record name: _kerberos-master._tcp
>   SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100
> 88 swir
>
>   Record name: _kpasswd._tcp
>   SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 464 dzien, 0 100
> 464 whale
>
>   Record name: _ldap._tcp
>   SRV record: 0 100 389 swir, 0 100 389 dzien, 0 100 389 whale, 0 100
> 389 rider
>
>   Record name: _kerberos._udp
>   SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100
> 88 swir
>
>   Record name: _kerberos-master._udp
>   SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100
> 88 swir
>
>   Record name: _kpasswd._udp
>   SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 464 dzien, 0 100
> 464 whale
>
>   Record name: _ntp._udp
>   SRV record: 0 100 123 dzien, 0 100 123 rider, 0 100 123 whale, 0
> 100 123 swir
>
> thanks.
> L.
>


 Hello,

 if server work5 is uninstalled, then work5 SRV records should be 
 removed.

 Martin
>>>
>>> Martin, would you be able suggest a way to troubleshoot that problem
>>> that one (only) server (rider) seems to present no data for the whole
>>> domain? Remaining servers correctly respond to any queries. One curious
>>> thing is that I $rndc trace 6; and (I see debug level changed in
>>> journalctl) I do not see anything in the logs when I query.
>>> Zone allows any to query it.
>>>
>>>
>>
>> What dig @rider  command returns for SRV queries?
>>
> don't mind SRV records for now, it returns no record at all, it forwards
> and caches but not for the domain itself.
> on rider (suffice I point to other member server and records are there)
>
> $ dig +qr any .xx.xx..xx.xx.x. @10.5.6.100
>
> ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.4 <<>> +qr any .xx.xx..xx.xx.x.
> @10.5.6.100
> ;; global options: +cmd
> ;; Sending:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36196
> ;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;.xx.xx..xx.xx.x. IN ANY
>
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36196
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;.xx.xx..xx.xx.x. IN ANY
>
> ;; AUTHORITY SECTION:
> .xx.xx.x.  3600  IN  SOA ipreg.xxx.xx.xx.x. hostmaster.xx.xx.x.
> 1478696070 1800 900 604800 

Re: [Freeipa-users] attrlist_replace - attr_replace : failed

[Petr Spacek]

On 8.11.2016 15:19, lejeczek wrote:
> hi everyone
> 
> I have a three servers which seemingly!? work but all three log:
> 
> attrlist_replace - attr_replace (nsslapd-referral, ldap://swir.xx.xx
> 
> and swir.xx.xx is the server which ipa-replica-prepared and on it I see:
> 
> attrlist_replace - attr_replace (nsslapd-referral, ldap://whale.xx.xx
> ...
> Error: could not bind id [cn=Replication Manager
> masterAgreement1-swir.xx.xx-pki-tomcat,ou=csusers,cn=config] authentication
> mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success)
> 
> where is it going wrong?

You redacted too much of the log but from what I can see, I guess that it is 
this:

http://www.freeipa.org/page/Troubleshooting#Obsolete_RUV_records

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA + DHCP-LDAP - Fedora 24 - broken

[Petr Spacek]

On 7.11.2016 17:45, Raul Dias wrote:
> You are right,
> 
> This might be more a Fedora issue than FreeIPA. I am hoping that someone else
> is also using DHCP with LDAP (specially with FreeIPA).
> 
> I am using the IPA-dhcp plugin: https://github.com/jefferyharrell/IPA-dhcp
> 
> ldapsearch -x shows the entries are fine in the LDAP.
> 
> Stracing dhcpd shows that it is not making any connection to the LDAP, while
> it shows an error message.
> 
> On Fedora 24 (updated), I am using dhcp-server-4.3.4.fc24
> 
> /etc/dhcp/dhcpd.conf:
> ldap-server "10.101.1.1"; #or localhost, or any interface ip or ns name
> ldap-port 389;
> ldap-base-dn "cn=dhcp,dc=dias,dc=com,dc=br";
> ldap-method static;
> ldap-debug-file "/var/log/dhcp-ldap-startup.log";
> 
> The STDERR output acts as if it were talking to the LDAP server:
> 
> Cannot find host LDAP entry server.dias.com.br
> (&(objectClass=dhcpServer)(cn=server.dias.com.br))
> 
> As the output of ldapsearch, the entry is there:
> # server.dias.com.br, dhcp, dias.com.br
> dn: cn=server.dias.com.br,cn=dhcp,dc=dias,dc=com,dc=br
> objectClass: dhcpserver
> objectClass: top
> dhcpServiceDN: cn=dhcp,dc=dias,dc=com,dc=br
> cn: server.dias.com.br
> dhcpStatements: authoritative
> 
> Using the same config on a ubuntu host, it works fine, which makes me wonder
> that dhcpd in Fedora 24 does not work at all with LDAP.

Do you mean that dhcpd on Ubuntu is configured against the very same FreeIPA
server?

Are you sure that dhcpd is using the same credentials to BIND to LDAP? There
might be an access control issue if different hosts use different credentials
or so. It would help if you described how you bound to LDAP using ldapsearch.

Petr^2 Spacek

> 
> Or maybe this is a reflection of some FreeIPA server way of life
> configuration, like sssd.
> 
> -rsd
> 
> 
> On 07/11/2016 05:10, Petr Spacek wrote:
>> On 6.11.2016 06:06, Raul Dias wrote:
>>> Hello,
>>>
>>> It seems that DHCP with LDAP on Fedora 24 (FreeIPA) is broken.
>>>
>>> Can anyone confirm?
>>>
>>> Doing an strace -e trace=network does not show any attempt to connect to the
>>> ldap server.
>>>
>>> OTOH, the same config on a Ubuntu 16.10 works fine.
>> Hello,
>>
>> AFAIK DHCP support was never part of official FreeIPA builds. What are you
>> trying to achieve and where did you get the builds?
>>
>> We need to know exact software versions and configuration. For further hints
>> how to report bugs please see
>> http://www.freeipa.org/page/Troubleshooting#Reporting_bugs
>>
> 


-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA + DHCP-LDAP - Fedora 24 - broken

[Petr Spacek]

On 6.11.2016 06:06, Raul Dias wrote:
> Hello,
> 
> It seems that DHCP with LDAP on Fedora 24 (FreeIPA) is broken.
> 
> Can anyone confirm?
> 
> Doing an strace -e trace=network does not show any attempt to connect to the
> ldap server.
> 
> OTOH, the same config on a Ubuntu 16.10 works fine.

Hello,

AFAIK DHCP support was never part of official FreeIPA builds. What are you
trying to achieve and where did you get the builds?

We need to know exact software versions and configuration. For further hints
how to report bugs please see
http://www.freeipa.org/page/Troubleshooting#Reporting_bugs

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] dns_tkey_negotiategss: failure GSSAPI error [...] Message stream modified.

[Petr Spacek]

On 27.10.2016 21:47, Tyrell Jentink wrote:
> Thank you Petr!  I found the problem, but quite by accident...  There may
> be a Best Practice at hand that I wasn't aware of...
> 
> I still have the Windows AD server sitting on the side, serving as DHCP
> server and waiting patiently for my Cross Realm Trust;  That server will
> forward DNS requests to the IPA server, and return a non-authoritative
> answer.  Occasionally, that server will seemingly loose track of the IPA
> server, and stop returning results...  And that happened while I was trying
> to follow through with your request for info...  So as a quick work around,
> I simply dropped the AD server from my resolv.conf...
> 
> And then performed your requests, without errors.  I ran the DNS Update
> from the ipa-server-install script, and that worked without errors.  I
> added the AD server back into resolv.conf, and everything failed again. I
> put the AD server as the SECOND name server in resolv.conf, and the errors
> went away. So I've clearly identified the problem.
> 
> I uninstalled the client, and reinstalled the client, and everything went
> cleanly.
> 
> To prevent this problem in the future...  I will be changing the DHCP
> options to list the IPA DNS first for the Linux clients, and the AD DNS
> first for Windows clients; I still want the AD DNS server in the list, as a
> fallback. Is this plan the best practice here?

Well, the ordering of the servers does not matter as long as they can resolve
records properly. The key problem is

> answer.  Occasionally, that server will seemingly loose track of the IPA
> server, and stop returning results...  And that happened while I was trying
...

It should just work if you fix this.

I hope it helps.

Petr Spacek  @  Red Hat

> 
> On Wed, Oct 26, 2016 at 11:36 PM, Petr Spacek <pspa...@redhat.com> wrote:
> 
>> On 27.10.2016 04:43, Tyrell Jentink wrote:
>>>> 2016-10-26T23:30:40Z DEBUG Writing nsupdate commands to
>>>>> /etc/ipa/.dns_update.txt:
>>>>> 2016-10-26T23:30:40Z DEBUG debug
>>>>>
>>>>> update delete trainmaster.ipa.rxrhouse.net. IN A
>>>>> show
>>>>> send
>>>>>
>>>>> update delete trainmaster.ipa.rxrhouse.net. IN 
>>>>> show
>>>>> send
>>>>>
>>>>> update add trainmaster.ipa.rxrhouse.net. 1200 IN A 10.42.0.100
>>>>> show
>>>>> send
>>>>>
>>>>> 2016-10-26T23:30:40Z DEBUG Starting external process
>>>>> 2016-10-26T23:30:40Z DEBUG args=/usr/bin/nsupdate -g
>>>>> /etc/ipa/.dns_update.txt
>>>>> 2016-10-26T23:30:40Z DEBUG Process finished, return code=1
>>>>> 2016-10-26T23:30:40Z DEBUG stdout=Outgoing update query:
>>>>> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  0
>>>>> ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
>>>>> ;; UPDATE SECTION:
>>>>> trainmaster.ipa.rxrhouse.net. 0 ANY A
>>>>>
>>>>> Outgoing update query:
>>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  39562
>>>>> ;; flags:; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>>>>> ;; QUESTION SECTION:
>>>>> ;3107127915.sig-ipa-pdc.ipa.rxrhouse.net. ANY TKEY
>>>>>
>>>>> ;; ADDITIONAL SECTION:
>>>>> 3107127915.sig-ipa-pdc.ipa.rxrhouse.net. 0 ANY TKEY gss-tsig.
>> 1477524640
>> [...]
>>>>>
>>>>> 2016-10-26T23:30:40Z DEBUG stderr=Reply from SOA query:
>>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  38738
>>>>> ;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1,
>> ADDITIONAL: 0
>>>>> ;; QUESTION SECTION:
>>>>> ;trainmaster.ipa.rxrhouse.net.  IN  SOA
>>>>>
>>>>> ;; AUTHORITY SECTION:
>>>>> ipa.rxrhouse.net.   0   IN  SOA
>> ipa-pdc.ipa.rxrhouse.net.
>>>>> hostmaster.ipa.rxrhouse.net. 1477524446 3600 900 1209600 3600
>>>>>
>>>>> Found zone name: ipa.rxrhouse.net
>>>>> The master is: ipa-pdc.ipa.rxrhouse.net
>>>>> start_gssrequest
>>>>> Found realm from ticket: IPA.RXRHOUSE.NET
>>>>> send_gssrequest
>>>>> recvmsg reply from GSS-TSIG query
>>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  39562
>>>>> ;; flags: qr; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
>>>>> ;; QUESTI

Re: [Freeipa-users] Is this a bigger Problem DNSSEC ?

[Petr Spacek]

On 25.10.2016 15:49, Günther J. Niederwimmer wrote:
> Hello,
> 
> FreeIPA 4.3.1
> CentOS 7.2
> 
> 
> I found today in /var/log/messages this entries 
> 
> Is the DNSSEC now broken ?
> 
> Thanks for a answer
> 
> ct 25 15:41:29 ipa ipa-dnskeysyncd: Traceback (most recent call last):
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: File "/usr/libexec/ipa/ipa-dnskeysyncd", 
> line 112, in 
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: while 
> ldap_connection.syncrepl_poll(all=1, msgid=ldap_search):
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: File "/usr/lib64/python2.7/site-
> packages/ldap/syncrepl.py", line 405, in syncrepl_poll
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: self.syncrepl_refreshdone()
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: File "/usr/lib/python2.7/site-
> packages/ipapython/dnssec/keysyncer.py", line 118, in syncrepl_refreshdone
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: self.bindmgr.sync(self.dnssec_zones)
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: File "/usr/lib/python2.7/site-
> packages/ipapython/dnssec/bindmgr.py", line 209, in sync
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: self.sync_zone(zone)
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: File "/usr/lib/python2.7/site-
> packages/ipapython/dnssec/bindmgr.py", line 182, in sync_zone
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: self.install_key(zone, uuid, attrs, 
> tempdir)
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: File "/usr/lib/python2.7/site-
> packages/ipapython/dnssec/bindmgr.py", line 117, in install_key
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: result = ipautil.run(cmd, 
> capture_output=True)
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: File "/usr/lib/python2.7/site-
> packages/ipapython/ipautil.py", line 479, in run
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: raise CalledProcessError(p.returncode, 
> arg_string, str(output))
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: subprocess.CalledProcessError: Command 
> '/usr/sbin/dnssec-keyfromlabel-pkcs11 -K /var/named/dyndb-
> ldap/ipa/master/4gjn.com/tmppaO_R2 -a RSASHA256 -l 
> pkcs11:object=d7fe5c98d5f3f89aefb9e8dfb92ebcb1;pin-
> source=/var/lib/ipa/dnssec/softhsm_pin -I 20160811091542 -D 20160825225503 -P 
> 20160513081600 -A 20160513081600 4gjn.com.' returned non-zero exit status 1
> Oct 25 15:41:30 ipa systemd: ipa-dnskeysyncd.service: main process exited, 
> code=exited, status=1/FAILURE
> Oct 25 15:41:30 ipa systemd: Unit ipa-dnskeysyncd.service entered failed 
> state.
> Oct 25 15:41:30 ipa systemd: ipa-dnskeysyncd.service failed.

It might break in future, when keys are rotated.

Please follow
http://www.freeipa.org/page/Troubleshooting#DNSSEC_signing_does_not_work

This debugging option might get handy, too:
http://www.freeipa.org/page/Troubleshooting#ipa_command_crashes_or_returns_no_data


-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] dns_tkey_negotiategss: failure GSSAPI error [...] Message stream modified.

[Petr Spacek]

On 27.10.2016 04:43, Tyrell Jentink wrote:
>> 2016-10-26T23:30:40Z DEBUG Writing nsupdate commands to
>> > /etc/ipa/.dns_update.txt:
>> > 2016-10-26T23:30:40Z DEBUG debug
>> >
>> > update delete trainmaster.ipa.rxrhouse.net. IN A
>> > show
>> > send
>> >
>> > update delete trainmaster.ipa.rxrhouse.net. IN 
>> > show
>> > send
>> >
>> > update add trainmaster.ipa.rxrhouse.net. 1200 IN A 10.42.0.100
>> > show
>> > send
>> >
>> > 2016-10-26T23:30:40Z DEBUG Starting external process
>> > 2016-10-26T23:30:40Z DEBUG args=/usr/bin/nsupdate -g
>> > /etc/ipa/.dns_update.txt
>> > 2016-10-26T23:30:40Z DEBUG Process finished, return code=1
>> > 2016-10-26T23:30:40Z DEBUG stdout=Outgoing update query:
>> > ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  0
>> > ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
>> > ;; UPDATE SECTION:
>> > trainmaster.ipa.rxrhouse.net. 0 ANY A
>> >
>> > Outgoing update query:
>> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  39562
>> > ;; flags:; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>> > ;; QUESTION SECTION:
>> > ;3107127915.sig-ipa-pdc.ipa.rxrhouse.net. ANY TKEY
>> >
>> > ;; ADDITIONAL SECTION:
>> > 3107127915.sig-ipa-pdc.ipa.rxrhouse.net. 0 ANY TKEY gss-tsig. 1477524640
[...]
>> >
>> > 2016-10-26T23:30:40Z DEBUG stderr=Reply from SOA query:
>> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  38738
>> > ;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>> > ;; QUESTION SECTION:
>> > ;trainmaster.ipa.rxrhouse.net.  IN  SOA
>> >
>> > ;; AUTHORITY SECTION:
>> > ipa.rxrhouse.net.   0   IN  SOA ipa-pdc.ipa.rxrhouse.net.
>> > hostmaster.ipa.rxrhouse.net. 1477524446 3600 900 1209600 3600
>> >
>> > Found zone name: ipa.rxrhouse.net
>> > The master is: ipa-pdc.ipa.rxrhouse.net
>> > start_gssrequest
>> > Found realm from ticket: IPA.RXRHOUSE.NET
>> > send_gssrequest
>> > recvmsg reply from GSS-TSIG query
>> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  39562
>> > ;; flags: qr; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
>> > ;; QUESTION SECTION:
>> > ;3107127915.sig-ipa-pdc.ipa.rxrhouse.net. ANY TKEY
>> >
>> > ;; ANSWER SECTION:
>> > 3107127915.sig-ipa-pdc.ipa.rxrhouse.net. 0 ANY TKEY gss-tsig. 1466301805
>> > 1466388205 3 NOERROR 101
>> > YGMGCSqGSIb3EgECAgMAflQwUqADAgEFoQMCAR6kERgPMjAxNjA2MTkw
>> > MjAzMjVapQUCAwHGkaYDAgEpqREbD0FELlJYUkhPVVNFLk5FVKoUMBKg
>> > AwIBAaELMAkbB2FkLXBkYyQ=
>> > 0
>> >
>> > dns_tkey_negotiategss: failure GSSAPI error: Major = Unspecified GSS
>> > failure.  Minor code may provide more information, Minor = Message stream
>> > modified.
>> >
>> > 2016-10-26T23:30:40Z DEBUG nsupdate failed: Command '/usr/bin/nsupdate -g
>> > /etc/ipa/.dns_update.txt' returned non-zero exit status 1
>> > 2016-10-26T23:30:40Z ERROR Failed to update DNS records.
>> > 2016-10-26T23:30:40Z DEBUG DNS resolver: Query:
>> > trainmaster.ipa.rxrhouse.net IN A
>> > 2016-10-26T23:30:40Z DEBUG DNS resolver: No record.
>> > 2016-10-26T23:30:40Z DEBUG DNS resolver: Query:
>> > trainmaster.ipa.rxrhouse.net IN 
>> > 2016-10-26T23:30:40Z DEBUG DNS resolver: No record.
>> > 2016-10-26T23:30:40Z DEBUG DNS resolver: Query: 100.0.42.10.in-addr.arpa.
>> > IN PTR
>> > 2016-10-26T23:30:40Z DEBUG DNS resolver: No record.
>> > 2016-10-26T23:30:40Z WARNING Missing A/ record(s) for host
>> > trainmaster.ipa.rxrhouse.net: 10.42.0.100.
>> > 2016-10-26T23:30:40Z WARNING Missing reverse record(s) for address(es):
>> > 10.42.0.100.
>> >
> -- Full logs can be found here:  http://pastebin.com/90dG9Ffu
> 
>- For grins, I decided to test:
>kinit admin
>id admin
>getent passwd admin
>on the client, and all of those all made valid responses... So
>authentication is working, I just can't update DNS records.
> 
> 
> So that's what I've tried, and where I'm at...  My client machines running
> modern client software can NOT update DNS records, complaining about GSSAPI
> "Message Stream Modified" errors...  And I have no idea how to troubleshoot
> that... Any ideas?

Interesting, I haven't seen this one :-)

There is something fishy in GSSAPI negotiation between the client and DNS 
server.

I would try this (and watch out for suspicious messages along the way):

1) To be sure, please double-check that ipa-pdc.ipa.rxrhouse.net. resolves
(from the client) to correct IP address of IPA DNS server.

2) Verify that Kerberos ticket for the DNS server can be obtained:
$ kinit -k
$ kvno DNS/ipa-pdc.ipa.rxrhouse.net
$ klist  # it should list Kerberos ticket for ipa-pdc.ipa.rxrhouse.net

3) Create a plain text file with update message content:
cat > /tmp/dnsupdate <

Re: [Freeipa-users] Lots of error messages in logs after upgrade

[Petr Spacek]

On 19.10.2016 10:14, Ludwig Krispenz wrote:
> 
> On 10/19/2016 09:39 AM, Prashant Bapat wrote:
>> Some more info.
>>
>> This is happening on one of the hosts for which replica-info file was
>> generated but for some reason the replica installation failed. So I went
>> ahead and deleted and created the replica file again and this time
>> installation went thru fine. Should this cause logs like this ?
> you now have two replicaids with the same url, you need to do a cleanruv as
> discussed frequently on this list

For reference, it is described here:
http://www.freeipa.org/page/Troubleshooting#Obsolete_RUV_records

Petr^2 Spacek

>>
>> These messages are seen every 5 mins.
>>
>> On 18 October 2016 at 22:38, Prashant Bapat > > wrote:
>>
>> Hi,
>>
>> I'm seeing lots of error messages like this in the DS logs.
>>
>> [18/Oct/2016:17:00:37 +] attrlist_replace - attr_replace
>> (nsslapd-referral,
>> ldap://ipa-primary.example.net:389/dc%3Dexample%2Cdc%3Dnet
>> ) failed.
>> [18/Oct/2016:17:00:37 +] attrlist_replace - attr_replace
>> (nsslapd-referral,
>> ldap://ipa-primary.example.net:389/dc%3Dexample%2Cdc%3Dnet
>> ) failed.
>> [18/Oct/2016:17:00:37 +] attrlist_replace - attr_replace
>> (nsslapd-referral,
>> ldap://ipa-primary.example.net:389/dc%3Dexample%2Cdc%3Dnet
>> ) failed.
>> [18/Oct/2016:17:00:46 +] attrlist_replace - attr_replace
>> (nsslapd-referral,
>> ldap://ipa-primary.example.net:389/dc%3Dexample%2Cdc%3Dnet
>> ) failed.
>> [18/Oct/2016:17:00:46 +] attrlist_replace - attr_replace
>> (nsslapd-referral,
>> ldap://ipa-primary.example.net:389/dc%3Dexample%2Cdc%3Dnet
>> ) failed.
>> [18/Oct/2016:17:00:46 +] attrlist_replace - attr_replace
>> (nsslapd-referral,
>> ldap://ipa-primary.example.net:389/dc%3Dexample%2Cdc%3Dnet
>> ) failed.
>> [18/Oct/2016:17:00:46 +] attrlist_replace - attr_replace
>> (nsslapd-referral,
>> ldap://ipa-primary.example.net:389/dc%3Dexample%2Cdc%3Dnet
>> ) failed.
>> [18/Oct/2016:17:00:46 +] attrlist_replace - attr_replace
>> (nsslapd-referral,
>> ldap://ipa-primary.example.net:389/dc%3Dexample%2Cdc%3Dnet
>> ) failed.
>> [18/Oct/2016:17:00:46 +] attrlist_replace - attr_replace
>> (nsslapd-referral,
>> ldap://ipa-primary.example.net:389/dc%3Dexample%2Cdc%3Dnet
>> ) failed.
>>
>> We moved from 4.1.4 (FC21) to 4.2.0 (Centos7.2) recently. We have
>> total 8 IPA servers with replication. Below are the steps I followed.
>>
>> 1. Install a new Centos server.
>> 2. Replicated against a Fedora server with CA.
>> 3. Moved the DNA ranges.
>> 4. From the Centos master created replicas.
>>
>> Is this related to the DS package version ? We
>> have 389-ds-base-1.3.4.0-33.el7_2.x86_64.
>>
>> Thanks.
>> --Prashant
>>
>>
>>
>>
> 
> 
> 


-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] DNS question on named.ca

[Petr Spacek]

On 19.10.2016 00:55, Sean Hogan wrote:
> 
> Hi all,
> 
>I have a DNS question on how/why my IPA DNS servers are trying to hit
> the root DNS internet servers.  My IPA servers are in private networks only
> serving DNS for the private domains they manage but recently the network
> team
> indicated they see my ipa IPs trying to hit the outside world.  After
> obtaining the logs I noticed they are trying to hit the internet root DNS
> servers.  I then tracked down named.ca on the IPAs which correlates to the
> IPs the network
> team is showing.  I then found named.conf references named.ca for hints.
> 
> This is where I imagine it is coming from in named.conf
> 
> zone "." IN {
>   type hint;
>   file "named.ca";
> };
> 
> Question is how can I stop my IPA DNS servers from trying to hit the
> internet root DNS servers?  

The answer depends on your environment.

If you are on isolated network and *have your own DNS root domain*, you have
couple of options:
a) specify only IP addresses of your root servers to named.ca file (recommended)

b) use global forwarding with policy only to forward to some other DNS server,
which is properly configured

c) add the root zone to IPA and configure *other* servers with root hints or
forwarders (just create zone named '.' and add appropriate delegations to
sub-zones as usual)


If your requirement is to have IPA DNS servers which do not reply to anything
else except DNS zones they are authoritative for, set allow-recursion policy
to "none;". In that case BIND will not run recursive resolution and thus not
try to contact root servers. It needs to be set in /etc/named.conf, IPA does
not support this setting.

Beware, IPA installer may rewrite named.conf when you run ipa-dns-install or
so. In that case just edit it again.

For all the gory details please see
https://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/Bv9ARM.ch06.html

I hope it helps.

Petr^2 Spacek


> I was thinking commenting out named.ca in
> named.conf but imagine bad things happening.
> I guess I could also make a new file for named.ca and reference it in
> named.conf...then scp it to the other ipas but no idea as to the syntax
> (giving it a shot at bottom of email) or if it can be empty.  Any help is
> appreciated.
> 
> 
> IPA clients resolv.conf are set for search domain and the nameserver IPs of
> the IPA servers.
> 
> Versions:
> ipa-server-3.0.0-50.el6.1.x86_64
> bind-9.8.2-0.47.rc1.el6.x86_64
> 
> Commands used for server install:
>  ipa-server-install --setup-dns
> 
> 
> 
> Attempt at correct syntax if I need a file with info in it..file named say
> fakenamed.ca
> If my IPA servers are named DNS1  10.10.10.1/2001:7fd::1 and DNS2
> 10.10.10.2/2001:503:c27::2:30 would this work or not even need?
> 
> ; OPERATED BY ME
> ;
> .360  NSDNS1.
> DNS1.  360  A 10.10.10.1
> DNS1.  360    2001:7fd::1
> ;
> ; OPERATED BY ME
> ;
> .360  NSDNS2.
> DNS2.  360  A 10.10.10.2
> DNS2.  360    2001:503:c27::2:30
> 
> 
> 
> Sean Hogan

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] bind-dyndb-ldap issues

[Petr Spacek]

On 13.10.2016 01:42, Brendan Kearney wrote:
> On 10/12/2016 02:35 AM, Petr Spacek wrote:
>> Hello,
>>
>> these are debug messages and are harmless. Apparently you have verbose/debug
>> messages enabled in named.conf:
>>
>>  arg "verbose_checks yes";
>>
>> If you want to get rid of these messages, just remove the line.
>>
>> What version of bind-dyndb-ldap are you using?
>>
>> Sufficiently new versions should use SyncRepl to pull all data from LDAP to
>> memory (on start) so the read performance should be nearly identical as with
>> plain BIND.
>>
>> Of course, writes/DNS updates will generate load on your LDAP server so the
>> server needs to handle the load.
>>
>> Petr^2 Spacek
>>
>> On 11.10.2016 20:41, Brendan Kearney wrote:
>>> i am using bind-dyndb-ldap on fedora 24 without FreeIPA, and continue to 
>>> have
>>> my logs swamped with errors about "check failed" from settings.c and fwd.c. 
>>>  i
>>> am completely up to date with every package, so the latest versions of
>>> everything are installed.
>>>
>>> [settings.c : 420: setting_update_from_ldap_entry] check failed: ignore
>>> [settings.c : 436: setting_update_from_ldap_entry] check failed: ignore
>>> [fwd.c : 378: fwd_setting_isexplicit] check failed: not found
>>>
>>> i have two boxes running a named instance each, in a "master/master" config.
>>> each has the zone data configured per below.  the uri refers to the local ip
>>> of each server.
>>>
>>>  dynamic-db "bpk2.com" {
>>>  library "ldap.so";
>>>  arg "uri ldap://192.168.88.1/;;
>>>  arg "base cn=dns,ou=Daemons,dc=bpk2,dc=com";
>>>  arg "auth_method simple";
>>>  arg "bind_dn cn=dnsUser,dc=bpk2,dc=com";
>>>  arg "password dnsPass";
>>>
>>>  arg "fake_mname server1.bpk2.com.";
>>>  arg "dyn_update yes";
>>>  arg "connections 2";
>>>  arg "verbose_checks yes";
>>>  };
>>>
>>>  zone "." IN {
>>>  type hint;
>>>  file "named.ca";
>>>  };
>>>
>>>  include "/etc/named.rfc1912.zones";
>>>
>>> my dns container is defined in openldap as such:
>>>
>>> dn: cn=dns,ou=Daemons,dc=bpk2,dc=com
>>> cn: dns
>>> idnspersistentsearch: FALSE
>>> idnszonerefresh: 30
>>> objectclass: top
>>> objectclass: nsContainer
>>> objectclass: idnsConfigObject
>>>
>>> where and how can i find the source of my issue?  these issues are causing
>>> performance issues on the rest of my network.  because of these errors, ldap
>>> throws errors about deferred operations for binding, too many executing, and
>>> pending operations.  additionally, recursion also seems to be impacted.  
>>> this
>>> is noticed most when streaming content.  buffering, stuttering and 
>>> pixelation
>>> are seen in the video streams.  it could be the swamping of logs killing I/O
>>> or the actual recurision, but 100% the video issues are related.  the log
>>> events match up exactly with the buffering.
>>>
>>> i had this issue with bind-dyndb-ldap and fedora 20 up until i recently
>>> upgraded.  i went from F20 to F24, and put things on nice new SSDs, instead 
>>> of
>>> spinning disks.  the problem followed the upgrade.  are there configuration
>>> items i am missing?  are there tweaks i can do to improve something?  how 
>>> do i
>>> get rid of these errors, so dns performance (or the log swamping) is not
>>> affecting the rest of my network?
>>>
>>> thank you,
>>>
>>> brendan
> 
> i am running 10.1.1 on F24.
> 
> why or how would those error logs be related to LDAP seeing an influx of
> updates, 

Again, these are just debug logs. Do not get confused by word 'failed' here,
it just means that return code from a function is not ISC_R_SUCCESS. In some
cases it is expected and does not imply error condition. (You can mentally
replace word 'failed' with string 'debug: function returned ').

These two cases are just fine:
- ISC_R_IGNORE from setting_update_from_ldap_entry function means that there
was no update to particular setting in the LDAP a entry - plugin processe

Re: [Freeipa-users] bind-dyndb-ldap issues

[Petr Spacek]

Hello,

these are debug messages and are harmless. Apparently you have verbose/debug
messages enabled in named.conf:

arg "verbose_checks yes";

If you want to get rid of these messages, just remove the line.

What version of bind-dyndb-ldap are you using?

Sufficiently new versions should use SyncRepl to pull all data from LDAP to
memory (on start) so the read performance should be nearly identical as with
plain BIND.

Of course, writes/DNS updates will generate load on your LDAP server so the
server needs to handle the load.

Petr^2 Spacek

On 11.10.2016 20:41, Brendan Kearney wrote:
> i am using bind-dyndb-ldap on fedora 24 without FreeIPA, and continue to have
> my logs swamped with errors about "check failed" from settings.c and fwd.c.  i
> am completely up to date with every package, so the latest versions of
> everything are installed.
> 
> [settings.c : 420: setting_update_from_ldap_entry] check failed: ignore
> [settings.c : 436: setting_update_from_ldap_entry] check failed: ignore
> [fwd.c : 378: fwd_setting_isexplicit] check failed: not found
> 
> i have two boxes running a named instance each, in a "master/master" config. 
> each has the zone data configured per below.  the uri refers to the local ip
> of each server.
> 
> dynamic-db "bpk2.com" {
> library "ldap.so";
> arg "uri ldap://192.168.88.1/;;
> arg "base cn=dns,ou=Daemons,dc=bpk2,dc=com";
> arg "auth_method simple";
> arg "bind_dn cn=dnsUser,dc=bpk2,dc=com";
> arg "password dnsPass";
> 
> arg "fake_mname server1.bpk2.com.";
> arg "dyn_update yes";
> arg "connections 2";
> arg "verbose_checks yes";
> };
> 
> zone "." IN {
> type hint;
> file "named.ca";
> };
> 
> include "/etc/named.rfc1912.zones";
> 
> my dns container is defined in openldap as such:
> 
> dn: cn=dns,ou=Daemons,dc=bpk2,dc=com
> cn: dns
> idnspersistentsearch: FALSE
> idnszonerefresh: 30
> objectclass: top
> objectclass: nsContainer
> objectclass: idnsConfigObject
> 
> where and how can i find the source of my issue?  these issues are causing
> performance issues on the rest of my network.  because of these errors, ldap
> throws errors about deferred operations for binding, too many executing, and
> pending operations.  additionally, recursion also seems to be impacted.  this
> is noticed most when streaming content.  buffering, stuttering and pixelation
> are seen in the video streams.  it could be the swamping of logs killing I/O
> or the actual recurision, but 100% the video issues are related.  the log
> events match up exactly with the buffering.
> 
> i had this issue with bind-dyndb-ldap and fedora 20 up until i recently
> upgraded.  i went from F20 to F24, and put things on nice new SSDs, instead of
> spinning disks.  the problem followed the upgrade.  are there configuration
> items i am missing?  are there tweaks i can do to improve something?  how do i
> get rid of these errors, so dns performance (or the log swamping) is not
> affecting the rest of my network?
> 
> thank you,
> 
> brendan

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA Server Hosting - Public Cloud vs Private Cloud

[Petr Spacek]

On 5.10.2016 11:16, Deepak Dimri wrote:
> Hi All,
> 
> I want to understand if there are any best practices wrt FreeIPA Server 
> deployment in Public vis a vis  Private cloud.  Lets assume a case that most 
> IPA Clients are hosted in private clouds at multiple data centers or across 
> AWS VPCs. In this situation hosting of freeIPA in the public cloud i reckon 
> would be an easier approach (clients can connect over the internet).  The 
> other option would be to host FreeIPA Server in private cloud, which would be 
> more secure,  but then you need to make changes in your network/FW settings 
> across private clouds. Are there any major security concerns if FreeIPA is 
> deployed in public cloud?
Properly configured FreeIPA can run on public Internet. I would recommend you
to read thread
https://www.redhat.com/archives/freeipa-users/2014-April/msg00246.html .

> Any examples of  freeIPA running in public cloud in production?

Here you go:
https://www.dragonsreach.it/2014/10/07/the-gnome-infrastructure-is-now-powered-by-freeipa/

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] IPA Server is not coming backup

[Petr Spacek]

Hi,

The important line is around

> named-pkcs11[3511]: GSSAPI Error: Unspecified GSS failure.  Minor code may
provide more information

Unfortunately the log is truncated so it does not show the actual error.

Please see
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart

I hope it helps.
Petr^2 Spacek

On 20.9.2016 12:45, Deepak Dimri wrote:
> Hi All,
> My IPA Server was working all fine until i tried restarting it using "ipactl 
> restart"  and now i am ended with these errors :( 
> 
> 
> 
> 
> 
> 
> 
> 
> [root@ip-172-31-25-165 plugins]# ipactl restartStarting Directory 
> ServiceRestarting krb5kdc ServiceRestarting kadmin ServiceStarting named 
> ServiceJob for named-pkcs11.service failed because the control process exited 
> with error code. See "systemctl status named-pkcs11.service" and "journalctl 
> -xe" for details.Failed to start named ServiceShutting down
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Aborting ipactl
> This is what i get with  "systemctl status named-pkcs11.service"
> [root@ip-172-31-25-165 plugins]# systemctl status named-pkcs11.service● 
> named-pkcs11.service - Berkeley Internet Name Domain (DNS) with native 
> PKCS#11   Loaded: loaded (/usr/lib/systemd/system/named-pkcs11.service; 
> disabled; vendor preset: disabled)   Active: failed (Result: exit-code) since 
> Tue 2016-09-20 06:28:03 EDT; 1min 2s ago  Process: 3281 
> ExecStart=/usr/sbin/named-pkcs11 -u named $OPTIONS (code=exited, 
> status=1/FAILURE)  Process: 3278 ExecStartPre=/bin/bash -c if [ ! 
> "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z 
> /etc/named.conf; else echo "Checking of zone files is disabled"; fi 
> (code=exited, status=0/SUCCESS)
> Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal 
> named-pkcs11[3284]: GSSAPI Error: Unspecified GSS failure.  Minor code may 
> provide more information (Server krbtgt/US-WEST-2.C...database)Sep 20 
> 06:28:03 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: LDAP 
> error: Local error: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS 
> failure.  Minor code may...er failedSep 20 06:28:03 
> ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: couldn't 
> establish connection in LDAP connection pool: failureSep 20 06:28:03 
> ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: dynamic 
> database 'ipa' configuration failed: failureSep 20 06:28:03 
> ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: loading 
> configuration: failureSep 20 06:28:03 
> ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3284]: exiting (due 
> to fatal error)Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal 
> systemd[1]: named-pkcs11.service: control process exited, code=exited 
> status=1Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal 
> systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) with native 
> PKCS#11.Sep 20 06:28:03 ip-172-31-25-165.us-west-2.compute.internal 
> systemd[1]: Unit named-pkcs11.service entered failed state.Sep 20 06:28:03 
> ip-172-31-25-165.us-west-2.compute.internal systemd[1]: named-pkcs11.service 
> failed.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Hint: Some lines were ellipsized, use -l to show in full.
> output from "journalctl -xe" is as below:
> [root@ip-172-31-25-165 ec2-user]# journalctl -xeSep 20 06:37:00 
> ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: option 
> 'serial_autoincrement' is not supported, ignoringSep 20 06:37:00 
> ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: GSSAPI client 
> step 1Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal 
> named-pkcs11[3511]: GSSAPI client step 1Sep 20 06:37:00 
> ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: GSSAPI Error: 
> Unspecified GSS failure.  Minor code may provide more information Sep 20 
> 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: LDAP 
> error: Local error: SASL(-1): generic failure: GSSAPI Error: Unspecified 
> GSSep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal 
> named-pkcs11[3511]: couldn't establish connection in LDAP connection pool: 
> failureSep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal 
> named-pkcs11[3511]: dynamic database 'ipa' configuration failed: failureSep 
> 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: 
> loading configuration: failureSep 20 06:37:00 
> ip-172-31-25-165.us-west-2.compute.internal named-pkcs11[3511]: exiting (due 
> to fatal error)Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal 
> systemd[1]: named-pkcs11.service: control process exited, code=exited 
> status=1Sep 20 06:37:00 ip-172-31-25-165.us-west-2.compute.internal 
> systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) with native 
> PKCS#11.-- Subject: Unit named-pkcs11.service has failed-- Defined-By: 
> systemd-- Support: 
> 

Re: [Freeipa-users] bind crashes on rndc reload

[Petr Spacek]

On 20.9.2016 00:33, Anthony Joseph Messina wrote:
> On Monday, September 19, 2016 2:16:55 PM CDT Petr Spacek wrote:
>> On 12.9.2016 11:55, Anthony Joseph Messina wrote:
>>> On Monday, September 12, 2016 10:31:10 AM CDT Jochen Demmer wrote:
>>>> Hi,
>>>>
>>>> I have a major issue with my setup:
>>>> Fedora 24
>>>> freeipa-common-4.3.2-2.fc24.noarch
>>>> freeipa-admintools-4.3.2-2.fc24.noarch
>>>> freeipa-server-dns-4.3.2-2.fc24.noarch
>>>> freeipa-client-common-4.3.2-2.fc24.noarch
>>>> freeipa-server-4.3.2-2.fc24.x86_64
>>>> freeipa-server-common-4.3.2-2.fc24.noarch
>>>> freeipa-client-4.3.2-2.fc24.x86_64
>>>> bind-dyndb-ldap-9.0-3.fc24.x86_64
>>>> bind-libs-lite-9.10.4-1.P2.fc24.x86_64
>>>> bind-pkcs11-libs-9.10.4-1.P2.fc24.x86_64
>>>> bind99-libs-9.9.9-1.P2.fc24.x86_64
>>>> bind-utils-9.10.4-1.P2.fc24.x86_64
>>>> rpcbind-0.2.3-11.rc1.fc24.x86_64
>>>> bind-license-9.10.4-1.P2.fc24.noarch
>>>> bind-pkcs11-9.10.4-1.P2.fc24.x86_64
>>>> bind-9.10.4-1.P2.fc24.x86_64
>>>> bind-libs-9.10.4-1.P2.fc24.x86_64
>>>> bind99-license-9.9.9-1.P2.fc24.noarch
>>>> bind-pkcs11-utils-9.10.4-1.P2.fc24.x86_64
>>>>
>>>> It seems that there is a regular but not daily "rndc reload" sent to the
>>>> nameserver that leads to a crash of it. I sent a SIGHUP to the named
>>>> process, but that didn't lead to a crash. Only "rndc reload" does. It
>>>> does not crash EVERY time, but most of the times. I need to do an
>>>> "ipactl restart" in order to get the nameserver up and running again.
>>>>
>>>> I found this thread, but this doesn't give me any clues:
>>>> https://www.redhat.com/archives/freeipa-users/2012-May/msg00340.html
>>>>
>>>> This is what the log says:
>>>> http://paste.debian.net/818354/
>>>> Please understand that I obfuscated my IP addresses and domain names
>>>>
>>>> This is the strace:
>>>> http://paste.debian.net/818365/
>>>>
>>>> This is my named.conf:
>>>> http://paste.debian.net/818368/
>>>>
>>>> Hope someone can help.
>>>> Jochen
>>>
>>> I wish I could, as I have the same issue, usually early Sunday morning
>>> after some cron/timer job that reloads:
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1362162
>>
>> Could you please try bind-dyndb-ldap-10.1-1.fc24 from updates-testing?
>>
>> Alternatively the package can be downloaded from
>> http://koji.fedoraproject.org/koji/buildinfo?buildID=792505
>>
>> Please let me know if it fixes your problem or not.
> 
> bind-dyndb-ldap-10.1-1.fc24 from updates-testing seems to work, or at least 
> is 
> does not crash on rndc reload. I'll give it some time and see what happens, 
> since it didn't crash every time before either.  Thank you Petr.  -A

Thanks, I will be waiting for your observations!

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] bind crashes on rndc reload

[Petr Spacek]

On 12.9.2016 11:55, Anthony Joseph Messina wrote:
> On Monday, September 12, 2016 10:31:10 AM CDT Jochen Demmer wrote:
>> Hi,
>>
>> I have a major issue with my setup:
>> Fedora 24
>> freeipa-common-4.3.2-2.fc24.noarch
>> freeipa-admintools-4.3.2-2.fc24.noarch
>> freeipa-server-dns-4.3.2-2.fc24.noarch
>> freeipa-client-common-4.3.2-2.fc24.noarch
>> freeipa-server-4.3.2-2.fc24.x86_64
>> freeipa-server-common-4.3.2-2.fc24.noarch
>> freeipa-client-4.3.2-2.fc24.x86_64
>> bind-dyndb-ldap-9.0-3.fc24.x86_64
>> bind-libs-lite-9.10.4-1.P2.fc24.x86_64
>> bind-pkcs11-libs-9.10.4-1.P2.fc24.x86_64
>> bind99-libs-9.9.9-1.P2.fc24.x86_64
>> bind-utils-9.10.4-1.P2.fc24.x86_64
>> rpcbind-0.2.3-11.rc1.fc24.x86_64
>> bind-license-9.10.4-1.P2.fc24.noarch
>> bind-pkcs11-9.10.4-1.P2.fc24.x86_64
>> bind-9.10.4-1.P2.fc24.x86_64
>> bind-libs-9.10.4-1.P2.fc24.x86_64
>> bind99-license-9.9.9-1.P2.fc24.noarch
>> bind-pkcs11-utils-9.10.4-1.P2.fc24.x86_64
>>
>> It seems that there is a regular but not daily "rndc reload" sent to the
>> nameserver that leads to a crash of it. I sent a SIGHUP to the named
>> process, but that didn't lead to a crash. Only "rndc reload" does. It
>> does not crash EVERY time, but most of the times. I need to do an
>> "ipactl restart" in order to get the nameserver up and running again.
>>
>> I found this thread, but this doesn't give me any clues:
>> https://www.redhat.com/archives/freeipa-users/2012-May/msg00340.html
>>
>> This is what the log says:
>> http://paste.debian.net/818354/
>> Please understand that I obfuscated my IP addresses and domain names
>>
>> This is the strace:
>> http://paste.debian.net/818365/
>>
>> This is my named.conf:
>> http://paste.debian.net/818368/
>>
>> Hope someone can help.
>> Jochen
> 
> I wish I could, as I have the same issue, usually early Sunday morning after 
> some cron/timer job that reloads:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1362162

Could you please try bind-dyndb-ldap-10.1-1.fc24 from updates-testing?

Alternatively the package can be downloaded from
http://koji.fedoraproject.org/koji/buildinfo?buildID=792505

Please let me know if it fixes your problem or not.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Ubuntu 16.04 released with FreeIPA 4.3.1

[Petr Spacek]

On 31.8.2016 00:23, Timo Aaltonen wrote:
> On 29.08.2016 10:34, Timo Aaltonen wrote:
>> On 21.04.2016 22:01, Timo Aaltonen wrote:
>>>
>>> ps. Debian unstable will have 4.3.1 once the package has gone through
>>> the NEW queue because the packaging got split in certain ways
>>
>> No it did not, because the ftpmaster rejected the upload since it ships
>> with minified javascript which is not considered modifiable source code.
>> And the old version has now been removed from Debian because it was
>> unmaintainable.
>>
>> So I hope #5639 will be resolved at some point. Note that Debian doesn't
>> require the javascript to be minified during package build, just that
>> the source would ship the unminified copy as well.
> 
> Turns out it wasn't too much of an effort to pull in unminified bits of
> everything that is shipped minified (just ~630kB..), so I guess Freeipa
> will be uploaded back fairly soon...

Timo,

can you share script/procedure you used? It would save us some time spent on
re-inventing what you have done :-)

We need to see how complex change it would be so we could pull it into master
eventually.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Slow logins with multi site replication

[Petr Spacek]

On 25.8.2016 22:30, Jakub Hrozek wrote:
> On Thu, Aug 25, 2016 at 04:11:29PM +, Neal Harrington | i-Neda Ltd wrote:
>>>> Hi,
>>
>>>>
>>>> I am experiencing slow logins and sudo authentication for servers joined 
>>>> to my FreeIPA domain. I have been following the other recent thread on 
>>>> slow logins and believe my issue is different.
>>>>
>>>> I have replication setup with 2 FreeIPA servers at each of 3 sites. The 
>>>> replication is working well and I am able to login correctly on client 
>>>> servers with correct sudo permissions etc. Logins seem to take a long time 
>>>> however. There seems to be some kind of DNS/connection timeout issues, see 
>>>> the example below where the client times out on the auth01 server, then 
>>>> retries and connects. I have also seen it switch to an alternate IPA 
>>>> server on timeout. Total delay in this example is about 10 seconds however 
>>>> it can take longer (approx 30 seconds). It is worth mentioning that client 
>>>> servers in each site cannot connect to IPA servers is a different site - 
>>>> however in the example below the auth01 IPA server is in the same site as 
>>>> the client server. I'm not sure if there is any way to make the IPA 
>>>> clients site aware so they prefer to log in to a local server?
>>>>
>>>>
>>>> On the IPA servers themselves there is no noticeable delay and once I have 
>>>> authenticated with sudo once, subsequent attempts in the same login are 
>>>> also near instant. I have not been able to find any reason for this delay 
>>>> in any logs (which probably just means I'm not looking in the right place).
>>>>
>>>>
>>>> DNS servers are running on each IPA server and responding well whenever I 
>>>> have tested.
>>>>
>>>>
>>>> IPA Servers: CentOS 7.2.1511 running IPA 4.2.0 (from standard CentOS repo)
>>>>
>>>> Client servers: Ubuntu 14.04 running IPA 3.3.4 (From standard Ubuntu repo)
>>>>
>>>>
>>>> Any comments or suggestions greatly appreciated.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Neal.
>>>>
>>>>
>>>> Example sssd log for a "sudo -l" attempt.
>>>>
>>>> (Mon Aug 1 14:39:59 2016) [sssd[be[fqdn.com]]] [krb5_child_timeout]
>>>> (0x0040): Timeout for child [7430] reached. In case KDC is distant or
>>>> network is slow you may consider increasing value of krb5_auth_timeout.
>>>> (Mon Aug 1 14:39:59 2016) [sssd[be[fqdn.com]]] [krb5_auth_done] (0x0020):
>>>> child timed out!
>>>
>>> These debug messages seem to be telling you what the problem is. Have
>>> you tried how long does it take to kinit (preferably with
>>> KRB5_TRACE=/dev/stderr prepended) ?
>>
>> Hi Jakub,
>>
>> Thanks for your response and sorry for my delay in replying. kinit takes 
>> between 2 and 25 seconds to complete - the KRB5_TRACE option shows it trying 
>> a random auth server, timing out and trying another random server until it 
>> picks a local server which then completes almost immediately. This seems to 
>> confirm that the problem is simply the server tries to authenticate against 
>> a FreeIPA server that is unreachable and times out causing the randomly slow 
>> logins. Given 6 auth servers with only 2 on each site there is a ~ 10% 
>> chance of hitting 3 bad servers in a row before login succeeds - if each 
>> takes 20 seconds that would explain the random login times of a few sec - 1 
>> minute.
>>
>> If I enter the local kdc servers manually in the realm section of krb5.conf 
>> then ssh logins always happen in < 2sec - however I would prefer to avoid 
>> the manual step of configuring and updating this (planning to expand out to 
>> a few hundred servers over 4-5 sites). Manually setting these is likely to 
>> lead to mistakes and it just feels inelegant compared to DNS SRV records.
>>
>> I have seen https://www.freeipa.org/page/V4/DNS_Location_Mechanism which 
>> looks good but is a proposal from 2013 with no indications that it has 
>> actually been developed. I was also very interested by 
>> https://www.freeipa.org/page/Howto/IPA_locations which would be perfect - 
>> except the "ipa location-add" commands do not seem to be recognised by my 
>> FreeIPA installs.
>>
>> Am I missing a better way to handle the case of multiple locations with 
>> clients in Location A being unable to authenticate against FreeIPA servers 
>> at location B?
>>
>> Any suggestions greatly appreciated.
>>
>> Thanks,
>> Neal.
>>
> 
> Petr Spacek (CC) has been working lately in this area, but frankly I
> don't know what the status is or what a recommendation for current
> versions might be..

Hello,

Field "Target version: 4.4.0" on page
https://www.freeipa.org/page/V4/DNS_Location_Mechanism
is correct - the feature is implemented in FreeIPA 4.4.0.

Please stay tuned until your distribution provides sufficiently new version of
FreeIPA.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Two masters and one of them is desynchronized

[Petr Spacek]

Hi,

again, please always keep freeipa-users@redhat.com in Cc of your e-mails. This
is not a private support channel.

Ludwig, do you know if dataversion is expected to be consistent among all
replicas or not? I would not expect consistent values.

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Configuration_Command_and_File_Reference/rootdse-attributes.html#dataversion

did not answer this question. If we find out the right answer we should extend
the description in documentation.

Petr^2 Spacek

On 24.8.2016 12:12, bahan w wrote:
> Re.
> 
> I checked the conflicts but I didn't find any between the two servers.
> ###
> 
> ldapsearch -x -D "cn=directory manager" -W -b "dc="
> "nsds5ReplConflict=*" \* nsds5ReplConflict
> ###
> 
> The only thing I see is that one my master is in IPA 3.0.0.42 and another
> is IPA 3.0.0.47.
> The server with a problem of synchronization is 3.0.0.47.
> 
> Here is a partial result from the command on each server:
> ###
> ldapsearch -Y GSSAPI -h `hostname` -b "" -s base
> ###
> 
> On the server OK
> ###
> 
> vendorVersion: 389-Directory/1.2.11.15 B2015.247.1737
> dataversion: 020160823201940
> 
> ###
> 
> 
> On the server with the problem of sync :
> 
> ###
> 
> vendorVersion: 389-Directory/1.2.11.15 B2015.022.1831
> dataversion: 020160823195011
> ###
> 
> Is the field dataversion the timestamp of the last version of the ldap
> database ?
> 
> I'm going to increase loglevel to DEBUG this afternoon before anything.
> 
> I found this in the red hat doc :
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ipa-replica-manage.html
> 
> ###
> 28.5.4. Reinitializing IdM Servers
> When a replica is first created, the database of the master server is
> copied, completely, over to the replica database. This process is called
> *initialization*. If a server/replica is offline for a long period of time
> or there is some kind of corruption in its database, then the server can be
> re-initialized, with a fresh and updated set of data.
> This is done using the re-initialize command. The target server being
> initialized is the local host. The server or replica from which to pull the
> data to initialize the local database is specified in the --from option:
> 
> [root@server ~]# ipa-replica-manage re-initialize --from srv1.example.com
> 
> ###
> 
> Do you know if it is available in IPA 3.0.0.47 ?
> 
> Best regards.
> 
> Bahan
> 
> On Wed, Aug 24, 2016 at 11:50 AM, bahan w <bahanw042...@gmail.com> wrote:
> 
>> Hello Petr, Orion.
>>
>> I checked the errors log from the dirsrv on both masters and I found
>> nothing related to an error with the replication plugin.
>>
>> I also performed all the tests described in the link Petr provided. Thank
>> you for this. Every one of this command is OK on both masters.
>>
>> I'm checking the access logs from dirsrv now.
>>
>> Any other tracks to follow ? Increase the log level on the replica failing
>> to sync ?
>>
>> Best regards.
>>
>> Bahan
>>
>> On Wed, Aug 24, 2016 at 8:41 AM, Petr Spacek <pspa...@redhat.com> wrote:
>>
>>> On 23.8.2016 22:44, bahan w wrote:
>>>> Hello !
>>>>
>>>> I am using IPA 3.0.0 on RedHat 6.6 servers.
>>>>
>>>> I have two masters and this evening, I realized that one of them was
>>>> desynchronized, some users and groups were missing.
>>>>
>>>> I was wondering if there was an ipa command to resynchronize replica
>>> which
>>>> are not sync with the other ?
>>>
>>> First of all, it is necessary to find out replication does not work.
>>>
>>> Please see
>>> http://www.freeipa.org/page/Troubleshooting#Replication_issues
>>>
>>> --
>>> Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Two masters and one of them is desynchronized

[Petr Spacek]

Hi,

please keep freeipa-users@redhat.com in Cc.

If there are no problems indicated in log, is it really a problem with
replication or something else?

I would try

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Monitoring_Replication_Status.html#replication-monitoring-script

and see if replication is working or not.

Petr^2 Spacek

On 24.8.2016 11:50, bahan w wrote:
> Hello Petr, Orion.
> 
> I checked the errors log from the dirsrv on both masters and I found
> nothing related to an error with the replication plugin.
> 
> I also performed all the tests described in the link Petr provided. Thank
> you for this. Every one of this command is OK on both masters.
> 
> I'm checking the access logs from dirsrv now.
> 
> Any other tracks to follow ? Increase the log level on the replica failing
> to sync ?
> 
> Best regards.
> 
> Bahan
> 
> On Wed, Aug 24, 2016 at 8:41 AM, Petr Spacek <pspa...@redhat.com> wrote:
> 
>> On 23.8.2016 22:44, bahan w wrote:
>>> Hello !
>>>
>>> I am using IPA 3.0.0 on RedHat 6.6 servers.
>>>
>>> I have two masters and this evening, I realized that one of them was
>>> desynchronized, some users and groups were missing.
>>>
>>> I was wondering if there was an ipa command to resynchronize replica
>> which
>>> are not sync with the other ?
>>
>> First of all, it is necessary to find out replication does not work.
>>
>> Please see
>> http://www.freeipa.org/page/Troubleshooting#Replication_issues
>>
>> --
>> Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Freeipa 4.2.0 hangs intermittently

[Petr Spacek]

On 23.8.2016 18:44, Rakesh Rajasekharan wrote:
> I think thers something seriously wrong with my system
> 
> not able to run any  IPA commands
> 
> klist
> Ticket cache: KEYRING:persistent:0:0
> Default principal: ad...@xyz.com
> 
> Valid starting   Expires  Service principal
> 2016-08-23T16:26:36  2016-08-24T16:26:22  krbtgt/xyz@xyz.com
> 
> 
> [root@prod-ipa-master-1a :~] ipactl status
> Directory Service: RUNNING
> krb5kdc Service: RUNNING
> kadmin Service: RUNNING
> ipa_memcached Service: RUNNING
> httpd Service: RUNNING
> pki-tomcatd Service: RUNNING
> ipa-otpd Service: RUNNING
> ipa: INFO: The ipactl command was successful
> 
> 
> 
> [root@prod-ipa-master :~] ipa user-find p-testuser
> ipa: ERROR: Kerberos error: ('Unspecified GSS failure.  Minor code may
> provide more information', 851968)/("Cannot contact any KDC for realm '
> XYZ.COM'", -1765328228)
> 

This is weird because the server seems to be up.

Please follow
http://www.freeipa.org/page/Troubleshooting#Authentication.2FKerberos

Petr^2 Spacek

> 
> 
> Thanks
> 
> Rakesh
> 
> On Tue, Aug 23, 2016 at 10:01 PM, Rakesh Rajasekharan <
> rakesh.rajasekha...@gmail.com> wrote:
> 
>> i changed the loggin level to 4 . Modifying nsslapd-accesslog-level
>>
>> But, the hang is still there. though I dont see the sigfault now
>>
>>
>>
>>
>> On Tue, Aug 23, 2016 at 9:02 PM, Rakesh Rajasekharan <
>> rakesh.rajasekha...@gmail.com> wrote:
>>
>>> My disk was getting filled too fast
>>>
>>> logs under /var/log/dirsrv was coming around 5 gb quickly filling up
>>>
>>> Is there a way to make the logging less verbose
>>>
>>>
>>>
>>> On Tue, Aug 23, 2016 at 6:41 PM, Petr Spacek <pspa...@redhat.com> wrote:
>>>
>>>> On 23.8.2016 15:07, Rakesh Rajasekharan wrote:
>>>>> I was able to fix that may be temporarily... when i checked the
>>>> network..
>>>>> there was another process that was running and consuming a lot of
>>>> network (
>>>>> i have no idea who did that. I need to seriously start restricting
>>>> people
>>>>> access to this machine )
>>>>>
>>>>> after killing that perfomance improved drastically
>>>>>
>>>>> But now, suddenly I started experiencing the same hang.
>>>>>
>>>>> This time , I gert the following error when checked dmesg
>>>>>
>>>>> [  301.236976] ns-slapd[3124]: segfault at 0 ip 7f1de416951c sp
>>>>> 7f1dee1dba70 error 4 in libcos-plugin.so[7f1de4166000+b000]
>>>>> [ 1116.248431] TCP: request_sock_TCP: Possible SYN flooding on port 88.
>>>>> Sending cookies.  Check SNMP counters.
>>>>> [11831.397037] ns-slapd[22550]: segfault at 0 ip 7f533d82251c sp
>>>>> 7f5347894a70 error 4 in libcos-plugin.so[7f533d81f000+b000]
>>>>> [11832.727989] ns-slapd[22606]: segfault at 0 ip 7f6231eb951c sp
>>>>> 7f623bf2ba70 error 4 in libcos-plugin.so[7f6231eb6000+b00
>>>>
>>>> Okay, this one is serious. The LDAP server crashed.
>>>>
>>>> 1. Make sure all your packages are up-to-date.
>>>>
>>>> Please see
>>>> http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#d
>>>> ebugging-crashes
>>>> for further instructions how to debug this.
>>>>
>>>> Petr^2 Spacek
>>>>
>>>>>
>>>>> and in /var/log/dirsrv/example-com/errors
>>>>>
>>>>> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>>>> could
>>>>> not delete change record 3291138 (rc: 32)
>>>>> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>>>> could
>>>>> not delete change record 3291139 (rc: 32)
>>>>> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>>>> could
>>>>> not delete change record 3291140 (rc: 32)
>>>>> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>>>> could
>>>>> not delete change record 3291141 (rc: 32)
>>>>> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>>>> could
>>>>> not delete change record 3291142 (rc: 32)
>>>>> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord:
>>>> could
>>>>&

Re: [Freeipa-users] Two masters and one of them is desynchronized

[Petr Spacek]

On 23.8.2016 22:44, bahan w wrote:
> Hello !
> 
> I am using IPA 3.0.0 on RedHat 6.6 servers.
> 
> I have two masters and this evening, I realized that one of them was
> desynchronized, some users and groups were missing.
> 
> I was wondering if there was an ipa command to resynchronize replica which
> are not sync with the other ?

First of all, it is necessary to find out replication does not work.

Please see
http://www.freeipa.org/page/Troubleshooting#Replication_issues

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Freeipa 4.2.0 hangs intermittently

[Petr Spacek]

On 23.8.2016 15:07, Rakesh Rajasekharan wrote:
> I was able to fix that may be temporarily... when i checked the network..
> there was another process that was running and consuming a lot of network (
> i have no idea who did that. I need to seriously start restricting people
> access to this machine )
> 
> after killing that perfomance improved drastically
> 
> But now, suddenly I started experiencing the same hang.
> 
> This time , I gert the following error when checked dmesg
> 
> [  301.236976] ns-slapd[3124]: segfault at 0 ip 7f1de416951c sp
> 7f1dee1dba70 error 4 in libcos-plugin.so[7f1de4166000+b000]
> [ 1116.248431] TCP: request_sock_TCP: Possible SYN flooding on port 88.
> Sending cookies.  Check SNMP counters.
> [11831.397037] ns-slapd[22550]: segfault at 0 ip 7f533d82251c sp
> 7f5347894a70 error 4 in libcos-plugin.so[7f533d81f000+b000]
> [11832.727989] ns-slapd[22606]: segfault at 0 ip 7f6231eb951c sp
> 7f623bf2ba70 error 4 in libcos-plugin.so[7f6231eb6000+b00

Okay, this one is serious. The LDAP server crashed.

1. Make sure all your packages are up-to-date.

Please see
http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debugging-crashes
for further instructions how to debug this.

Petr^2 Spacek

> 
> and in /var/log/dirsrv/example-com/errors
> 
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> not delete change record 3291138 (rc: 32)
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> not delete change record 3291139 (rc: 32)
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> not delete change record 3291140 (rc: 32)
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> not delete change record 3291141 (rc: 32)
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> not delete change record 3291142 (rc: 32)
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> not delete change record 3291143 (rc: 32)
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> not delete change record 3291144 (rc: 32)
> [23/Aug/2016:12:49:36 +] DSRetroclPlugin - delete_changerecord: could
> not delete change record 3291145 (rc: 32)
> [23/Aug/2016:12:49:50 +] - Retry count exceeded in delete
> [23/Aug/2016:12:49:50 +] DSRetroclPlugin - delete_changerecord: could
> not delete change record 3292734 (rc: 51)
> 
> 
> Can  i do something about this error.. I treid to restart ipa a couple of
> time but that did not help
> 
> Thanks
> Rakesh
> 
> On Mon, Aug 22, 2016 at 2:27 PM, Petr Spacek <pspa...@redhat.com> wrote:
> 
>> On 19.8.2016 19:32, Rakesh Rajasekharan wrote:
>>> I am running my set up on AWS cloud, and entropy is low at around 180 .
>>>
>>> I plan to increase it bu installing haveged . But, would low entropy by
>> any
>>> chance cause this issue of intermittent hang .
>>> Also, the hang is mostly observed when registering around 20 clients
>>> together
>>
>> Possibly, I'm not sure. If you want to dig into this, I would do this:
>> 1. look what process hangs on client (using pstree command or so)
>> $ pstree
>>
>> 2. look to what server and port is the hanging client connected to
>> $ lsof -p 
>>
>> 3. jump to server and see what process is bound to the target port
>> $ netstat -pn
>>
>> 4. see where the process if hanging
>> $ strace -p 
>>
>> I hope it helps.
>>
>> Petr^2 Spacek
>>
>>> On Fri, Aug 19, 2016 at 7:24 PM, Rakesh Rajasekharan <
>>> rakesh.rajasekha...@gmail.com> wrote:
>>>
>>>> yes there seems to be something thats worrying.. I have faced this today
>>>> as well.
>>>> There are few hosts around 280 odd left and when i try adding them to
>> IPA
>>>> , the slowness begins..
>>>>
>>>> all the ipa commands like ipa user-find.. etc becomes very slow in
>>>> responding.
>>>>
>>>> the SYNC_RECV are not many though just around 80-90 and today that was
>>>> around 20 only
>>>>
>>>>
>>>> I have for now increased tcp_max_syn_backlog to 5000.
>>>> For now the slowness seems to have gone.. but I will do a try adding the
>>>> clients again tomorrow and see how it goes
>>>>
>>>> Thanks
>>>> Rakesh
>>>>
>>>> The issues
>>>>
>>>> On Fri, Aug 19, 2016 at 12:58 PM, Petr Spacek <pspa...@redhat.com>
>> wrote:
>>>>
>>>>> On 18.8.2016 17:2

Re: [Freeipa-users] Update NON-ipa Bind slave server from IPA-DNS edit/update

[Petr Spacek]

On 23.8.2016 13:21, Matt . wrote:
> And then allow the ip of the ipa server for update or tranfser on the slave ?
> 
> Because I don't see anything coming in.

The config has two parts:

1. master (IPA DNS)
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#zone-transfers

2. slave (non-IPA DNS)
http://www.zytrax.com/books/dns/ch4/index.html#slave

You need to configure both sides. Slave will then periodically pull the zone
and re-transfer zone whenever IPA DNS sends a NOTIFY message to the slave.

Log on slave should tell you if it is receiving something or not.

-- 
Petr^2 Spacek


> 
> 2016-08-23 12:47 GMT+02:00 Petr Spacek <pspa...@redhat.com>:
>> On 23.8.2016 12:43, Matt . wrote:
>>> OK, but what kind of records are you talking about then ?
>>
>> I'm not sure what else should I say.
>>
>> NS records: the ones added by
>>
>> $ ipa record-add  @ --ns-rec=.
>> (please note the trailing period)
>>
>> Does it answer your question?
>>
>> Petr^2 Spacek
>>
>>>
>>> 2016-08-23 12:25 GMT+02:00 Petr Spacek <pspa...@redhat.com>:
>>>> On 23.8.2016 09:07, Martin Basti wrote:
>>>>>
>>>>>
>>>>> On 23.08.2016 02:08, Matt . wrote:
>>>>>> Hi Guys,
>>>>>>
>>>>>> What is the way to notify or update a Bind slave which is not an IPA 
>>>>>> server ?
>>>>>>
>>>>>> Do I need to manuallu add an also-notify to the /etc/bind.conf on the
>>>>>> IPA master or is there a different way how to accomplish this ?
>>>>>>
>>>>>> I hope this is possible and anyone can explain me how.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Matt
>>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> some info about transfers can be found here:
>>>>> http://www.freeipa.org/page/Howto/DNS_updates_and_zone_transfers_with_TSIG
>>>>>
>>>>> Yes you need manually update named.conf with also-notify
>>>>
>>>> Well, the also-notify might not (always) work, it is not directly 
>>>> supported by
>>>> bind-dyndb-ldap.
>>>>
>>>> It should work automatically if you list your slave servers in NS records,
>>>> BIND will automatically send notify messages to all servers listed in NS 
>>>> records.
>>>>
>>>> --
>>>> Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Update NON-ipa Bind slave server from IPA-DNS edit/update

[Petr Spacek]

On 23.8.2016 12:43, Matt . wrote:
> OK, but what kind of records are you talking about then ?

I'm not sure what else should I say.

NS records: the ones added by

$ ipa record-add  @ --ns-rec=.
(please note the trailing period)

Does it answer your question?

Petr^2 Spacek

> 
> 2016-08-23 12:25 GMT+02:00 Petr Spacek <pspa...@redhat.com>:
>> On 23.8.2016 09:07, Martin Basti wrote:
>>>
>>>
>>> On 23.08.2016 02:08, Matt . wrote:
>>>> Hi Guys,
>>>>
>>>> What is the way to notify or update a Bind slave which is not an IPA 
>>>> server ?
>>>>
>>>> Do I need to manuallu add an also-notify to the /etc/bind.conf on the
>>>> IPA master or is there a different way how to accomplish this ?
>>>>
>>>> I hope this is possible and anyone can explain me how.
>>>>
>>>> Thanks!
>>>>
>>>> Matt
>>>>
>>>
>>> Hi,
>>>
>>> some info about transfers can be found here:
>>> http://www.freeipa.org/page/Howto/DNS_updates_and_zone_transfers_with_TSIG
>>>
>>> Yes you need manually update named.conf with also-notify
>>
>> Well, the also-notify might not (always) work, it is not directly supported 
>> by
>> bind-dyndb-ldap.
>>
>> It should work automatically if you list your slave servers in NS records,
>> BIND will automatically send notify messages to all servers listed in NS 
>> records.
>>
>> --
>> Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Update NON-ipa Bind slave server from IPA-DNS edit/update

[Petr Spacek]

On 23.8.2016 09:07, Martin Basti wrote:
> 
> 
> On 23.08.2016 02:08, Matt . wrote:
>> Hi Guys,
>>
>> What is the way to notify or update a Bind slave which is not an IPA server ?
>>
>> Do I need to manuallu add an also-notify to the /etc/bind.conf on the
>> IPA master or is there a different way how to accomplish this ?
>>
>> I hope this is possible and anyone can explain me how.
>>
>> Thanks!
>>
>> Matt
>>
> 
> Hi,
> 
> some info about transfers can be found here:
> http://www.freeipa.org/page/Howto/DNS_updates_and_zone_transfers_with_TSIG
> 
> Yes you need manually update named.conf with also-notify

Well, the also-notify might not (always) work, it is not directly supported by
bind-dyndb-ldap.

It should work automatically if you list your slave servers in NS records,
BIND will automatically send notify messages to all servers listed in NS 
records.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Freeipa 4.2.0 hangs intermittently

[Petr Spacek]

On 19.8.2016 19:32, Rakesh Rajasekharan wrote:
> I am running my set up on AWS cloud, and entropy is low at around 180 .
> 
> I plan to increase it bu installing haveged . But, would low entropy by any
> chance cause this issue of intermittent hang .
> Also, the hang is mostly observed when registering around 20 clients
> together

Possibly, I'm not sure. If you want to dig into this, I would do this:
1. look what process hangs on client (using pstree command or so)
$ pstree

2. look to what server and port is the hanging client connected to
$ lsof -p 

3. jump to server and see what process is bound to the target port
$ netstat -pn

4. see where the process if hanging
$ strace -p 

I hope it helps.

Petr^2 Spacek

> On Fri, Aug 19, 2016 at 7:24 PM, Rakesh Rajasekharan <
> rakesh.rajasekha...@gmail.com> wrote:
> 
>> yes there seems to be something thats worrying.. I have faced this today
>> as well.
>> There are few hosts around 280 odd left and when i try adding them to IPA
>> , the slowness begins..
>>
>> all the ipa commands like ipa user-find.. etc becomes very slow in
>> responding.
>>
>> the SYNC_RECV are not many though just around 80-90 and today that was
>> around 20 only
>>
>>
>> I have for now increased tcp_max_syn_backlog to 5000.
>> For now the slowness seems to have gone.. but I will do a try adding the
>> clients again tomorrow and see how it goes
>>
>> Thanks
>> Rakesh
>>
>> The issues
>>
>> On Fri, Aug 19, 2016 at 12:58 PM, Petr Spacek <pspa...@redhat.com> wrote:
>>
>>> On 18.8.2016 17:23, Rakesh Rajasekharan wrote:
>>>> Hi
>>>>
>>>> I am migrating to freeipa from openldap and have around 4000 clients
>>>>
>>>> I had openned a another thread on that, but chose to start a new one
>>> here
>>>> as its a separate issue
>>>>
>>>> I was able to change the nssslapd-maxdescriptors adding an ldif file
>>>>
>>>> cat nsslapd-modify.ldif
>>>> dn: cn=config
>>>> changetype: modify
>>>> replace: nsslapd-maxdescriptors
>>>> nsslapd-maxdescriptors: 17000
>>>>
>>>> and running the ldapmodify command
>>>>
>>>> I have now started moving clients running an openldap to Freeipa and
>>> have
>>>> today moved close to 2000 clients
>>>>
>>>> However, I have noticed that IPA hangs intermittently.
>>>>
>>>> running a kinit admin returns the below error
>>>> kinit: Generic error (see e-text) while getting initial credentials
>>>>
>>>> from the /var/log/messages, I see this entry
>>>>
>>>>  prod-ipa-master-int kernel: [104090.315801] TCP: request_sock_TCP:
>>>> Possible SYN flooding on port 88. Sending cookies.  Check SNMP counters.
>>>
>>> I would be worried about this message. Maybe kernel/firewall is doing
>>> something fishy behind your back and blocking some connections or so.
>>>
>>> Petr^2 Spacek
>>>
>>>
>>>> Aug 18 13:00:01 prod-ipa-master-int systemd[1]: Started Session 4885 of
>>>> user root.
>>>> Aug 18 13:00:01 prod-ipa-master-int systemd[1]: Starting Session 4885 of
>>>> user root.
>>>> Aug 18 13:01:01 prod-ipa-master-int systemd[1]: Started Session 4886 of
>>>> user root.
>>>> Aug 18 13:01:01 prod-ipa-master-int systemd[1]: Starting Session 4886 of
>>>> user root.
>>>> Aug 18 13:02:40 prod-ipa-master-int python[28984]: ansible-command
>>> Invoked
>>>> with creates=None executable=None shell=True args= removes=None
>>> warn=True
>>>> chdir=None
>>>> Aug 18 13:04:37 prod-ipa-master-int sssd_be: GSSAPI Error: Unspecified
>>> GSS
>>>> failure.  Minor code may provide more information (KDC returned error
>>>> string: PROCESS_TGS)
>>>>
>>>> Could it be possible that its due to the initial load of adding the
>>> clients
>>>> or is there something else that I need to take care of.

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Very slow enrolment process

[Petr Spacek]

On 22.8.2016 03:42, William Muriithi wrote:
> Hello,
> 
> I have systems that were previously using openLDAP and plan to migrate
> them to freeIPA.  I have a problem I have been struggling with since
> Thursday.  The client take 10 to 15 minutes to finish the enrolment
> process.
> 
> I can't find anything in the logs, have disabled nscd, the DNS and
> hostname is set up write and nothing on the message logs point me to
> the problem.  Have put se-linux to permissive and done all the basic
> checks I can think of.
> 
> Its always stalling at this point. What usually happen after the end
> of the log below?
> 
> ---
> 
> 2016-08-22T01:12:07Z INFO Synchronizing time with KDC...
> 
> 2016-08-22T01:12:07Z DEBUG Search DNS for SRV record of
> _ntp._udp.eng.example.com.
> 
> 2016-08-22T01:12:07Z DEBUG DNS record found:
> DNSResult::name:_ntp._udp.eng.example.com.,type:33,class:1,rdata={priority:0,port:123,weight:100,server:hydrogen.eng.example.com.}
> 
> 2016-08-22T01:12:08Z DEBUG args=/usr/sbin/ntpdate -U ntp -s -b -v
> hydrogen.eng.example.com
> 
> 2016-08-22T01:12:08Z DEBUG stdout=
> 
> 2016-08-22T01:12:08Z DEBUG stderr=
> 
> 2016-08-22T01:12:08Z DEBUG Writing Kerberos configuration to /tmp/tmpYLpzuV:
> 
> 2016-08-22T01:12:08Z DEBUG #File modified by ipa-client-install
> 
> 
> includedir /var/lib/sss/pubconf/krb5.include.d/
> 
> 
> [libdefaults]
> 
>   default_realm = ENG.EXAMPLE.COM
> 
>   dns_lookup_realm = false
> 
>   dns_lookup_kdc = false
> 
>   rdns = false
> 
>   ticket_lifetime = 24h
> 
>   forwardable = yes
> 
>   udp_preference_limit = 0
> 
> 
> 
> [realms]
> 
>   ENG.EXAMPLE.COM = {
> 
> kdc = hydrogen.eng.example.com:88
> 
> master_kdc = hydrogen.eng.example.com:88
> 
> admin_server = hydrogen.eng.example.com:749
> 
> default_domain = eng.example.com
> 
> pkinit_anchors = FILE:/etc/ipa/ca.crt
> 
> 
>   }
> 
> 
> 
> [domain_realm]
> 
>   .eng.example.com = ENG.EXAMPLE.COM
> 
>   eng.example.com = ENG.EXAMPLE.COM


This is interesting. This output is printed right before calling ipa-join
command so you should see follow-up line "Starting external process".

Is it somewhere in the file?

I cannot imagine where it could hang between write to the krb5.conf file and
starting ipa-join command...

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] dns/ldap failing after temporary storage problem

[Petr Spacek]

On 19.8.2016 16:13, Tiemen Ruiten wrote:
> I did actually use a local dse.ldif in the end, but I forgot to stop dirsrv
> while replacing it, so maybe the nsslapd-localhost line got updated by the
> running dirsrv?

Yes, that is possible. dirsrv can write to dse.ldif at run-time.

> 
> On 19 August 2016 at 15:59, Petr Spacek <pspa...@redhat.com> wrote:
> 
>> On 19.8.2016 15:26, Tiemen Ruiten wrote:
>>> Managed to fix it: had to stop dirsrv@IPA-RDMEDIA-COM and put the
>> server's
>>> hostname on the line with nsslapd-localhost
>>
>> Uh, this is quite brutal. There might be some other server-specific
>> options.
>>
>> If you can dig up older dse.ldif from the same server, I would rather
>> restore
>> that version. You never know what will silently break.
>>
>> Petr^2 Spacek
>>
>>>
>>> Then run ipa-replica-manage re-initialize --from
>>> other-master.ipa.rdmedia.com

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] dns/ldap failing after temporary storage problem

[Petr Spacek]

On 19.8.2016 15:26, Tiemen Ruiten wrote:
> Managed to fix it: had to stop dirsrv@IPA-RDMEDIA-COM and put the server's
> hostname on the line with nsslapd-localhost

Uh, this is quite brutal. There might be some other server-specific options.

If you can dig up older dse.ldif from the same server, I would rather restore
that version. You never know what will silently break.

Petr^2 Spacek

> 
> Then run ipa-replica-manage re-initialize --from
> other-master.ipa.rdmedia.com
> 
> On 19 August 2016 at 12:14, Tiemen Ruiten  wrote:
> 
>> I see lots of messages /var/log/dirsrv/slapd-IPA-RDMEDIA-COM/errors,
>> looks definitely like an issue with dirsrv.
>>
>> On 19 August 2016 at 11:43, Tiemen Ruiten  wrote:
>>
>>> I see I didn't use the right terminology: all four of my FreeIPA servers
>>> are masters.
>>>
>>> On 19 August 2016 at 11:36, Tiemen Ruiten  wrote:
>>>
 Hello,

 I need some help getting one of my replica's to work. Assistance would
 be much appreciated.

 After the iSCSI volumes of two replicas of were briefly unavailable, on
 one of them DNS and LDAP stopped working and replication seems to have
 stopped. The ipa service failed with a message that an upgrade was
 required, so I ran ipa-server-upgrade, but it failed due to an empty
 dse.ldif.

 Then I probably made a mistake by copying a dse.ldif from another
 replica and trying to run the upgrade. It worked more or less, but DNS
 still didn't work.

 Next I replaced it with an older backup file (from Aug 4) ran the
 upgrade command again and after some fiddling all services started
 normally, except ipa-dnskeysyncd:

 journalctl -u ipa-dnskeysyncd

 Aug 19 11:28:52 promethium.ipa.rdmedia.com systemd[1]:
 ipa-dnskeysyncd.service holdoff time over, scheduling restart.
 Aug 19 11:28:52 promethium.ipa.rdmedia.com systemd[1]: Started IPA key
 daemon.
 Aug 19 11:28:52 promethium.ipa.rdmedia.com systemd[1]: Starting IPA key
 daemon...
 Aug 19 11:28:52 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: ipa:
 WARNING: session memcached servers not running
 Aug 19 11:28:53 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: ipa
   : INFO LDAP bind...
 Aug 19 11:28:53 promethium.ipa.rdmedia.com python2[3756]: GSSAPI client
 step 1
 Aug 19 11:28:54 promethium.ipa.rdmedia.com python2[3756]: GSSAPI client
 step 1
 Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: ipa
   : ERRORLogin to LDAP server failed: {'info': 'SASL(-1): generic
 failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide
 more information (No key table entry found matching
 ldap/praseodymium.ipa.rdmedia.com@)', 'desc': 'Invalid credentials'}
 Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
 Traceback (most recent call last):
 Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
 "/usr/libexec/ipa/ipa-dnskeysyncd", line 92, in 
 Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
 ldap_connection.sasl_interactive_bind_s("", ipaldap.SASL_GSSAPI)
 Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
 "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 850, in
 sasl_interactive_bind_s
 Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: res =
 self._apply_method_s(SimpleLDAPObject.sasl_interactive_bind_
 s,*args,**kwargs)
 Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
 "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 818, in
 _apply_method_s
 Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
 return func(self,*args,**kwargs)
 Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
 "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 229, in
 sasl_interactive_bind_s
 Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
 return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,Req
 uestControlTuples(serverctrls),RequestControlTuples(clientct
 rls),sasl_flags)
 Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]: File
 "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in
 _ldap_call
 Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
 result = func(*args,**kwargs)
 Aug 19 11:28:55 promethium.ipa.rdmedia.com ipa-dnskeysyncd[3756]:
 INVALID_CREDENTIALS: {'info': 'SASL(-1): generic failure: GSSAPI Error:
 Unspecified GSS failure.  Minor code may provide more information (No key
 table entry found matching ldap/praseodymium.ipa.rdmedia.com@)',
 'desc': 'Invalid credentials'}

 praseodymium.ipa.rdmedia.com is the replica I copied the dse.ldif from.
 DNS and logins to 

Re: [Freeipa-users] Freeipa 4.2.0 hangs intermittently

[Petr Spacek]

On 18.8.2016 17:23, Rakesh Rajasekharan wrote:
> Hi
> 
> I am migrating to freeipa from openldap and have around 4000 clients
> 
> I had openned a another thread on that, but chose to start a new one here
> as its a separate issue
> 
> I was able to change the nssslapd-maxdescriptors adding an ldif file
> 
> cat nsslapd-modify.ldif
> dn: cn=config
> changetype: modify
> replace: nsslapd-maxdescriptors
> nsslapd-maxdescriptors: 17000
> 
> and running the ldapmodify command
> 
> I have now started moving clients running an openldap to Freeipa and have
> today moved close to 2000 clients
> 
> However, I have noticed that IPA hangs intermittently.
> 
> running a kinit admin returns the below error
> kinit: Generic error (see e-text) while getting initial credentials
> 
> from the /var/log/messages, I see this entry
> 
>  prod-ipa-master-int kernel: [104090.315801] TCP: request_sock_TCP:
> Possible SYN flooding on port 88. Sending cookies.  Check SNMP counters.

I would be worried about this message. Maybe kernel/firewall is doing
something fishy behind your back and blocking some connections or so.

Petr^2 Spacek


> Aug 18 13:00:01 prod-ipa-master-int systemd[1]: Started Session 4885 of
> user root.
> Aug 18 13:00:01 prod-ipa-master-int systemd[1]: Starting Session 4885 of
> user root.
> Aug 18 13:01:01 prod-ipa-master-int systemd[1]: Started Session 4886 of
> user root.
> Aug 18 13:01:01 prod-ipa-master-int systemd[1]: Starting Session 4886 of
> user root.
> Aug 18 13:02:40 prod-ipa-master-int python[28984]: ansible-command Invoked
> with creates=None executable=None shell=True args= removes=None warn=True
> chdir=None
> Aug 18 13:04:37 prod-ipa-master-int sssd_be: GSSAPI Error: Unspecified GSS
> failure.  Minor code may provide more information (KDC returned error
> string: PROCESS_TGS)
> 
> Could it be possible that its due to the initial load of adding the clients
> or is there something else that I need to take care of.
> 
> Thanks,
> 
> Rakesh

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA and slave MIT slave KDCs

[Petr Spacek]

On 18.8.2016 23:36, Diogenes S. Jesus wrote:
> Thanks Petr.
> 
> It seems like the only way to do it right now is to dump the keytab and
> copy it to slave KDCs, as I couldn't find a way to have MIT Kerberos to use
> the master key stored in the LDAP directly.

That is expected. If you want, just dump the key to file and distribute it
(using a secure mechanism). At the moment, FreeIPA does not rotate the master
key so it should just work.


> MIT Kerberos doesn't really support a master key stored elsewhere other
> than using "key_stash_file" AFAIK, so I'm wondering how FreeIPA has
> actually implemented it (I couldn't find any reference for it in the
> kerberos conf files).

FreeIPA has own KDC database driver:
https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-kdb?id=6b7d6417d403c983691c790c1e60cfe32bf1c420

This is why you cannot find this in standard MIT KDC.


> My use case involves having a "FreeIPA slave"  - a streamlined version
> which will only provide authentication (via Kerberos). Sure, I can make a
> standard replica and firewall what I don't wanna use, but when stretching
> your authentication infrastructure you don't necessary need to expose all
> other services FreeIPA provides, since that increases your attack surface.

Well, it should work if you leave all ports open for communication among
replicas but block out all clients.

In this case do not forget to remove DNS SRV records for other services so
clients do not timeout while attempting to contact firewalled replicas.

(Please note that FreeIPA DNS automatically re-generates DNS SRV records when
you change something in replica topology or run an IPA installer - you will
need to make the changes again.)


If you want to try the pure KDC slave, please let us know how it worked. I'm
curious :-)

Petr^2 Spacek


> Best regards
> 
> On Fri, Jul 22, 2016 at 10:14 AM, Petr Spacek <pspa...@redhat.com> wrote:
> 
>> On 21.7.2016 22:05, Diogenes S. Jesus wrote:
>>> Hi everyone.
>>>
>>> I'm currently planning on deploying FreeIPA as the Master KDC (among
>> other
>>> things to leverage from the API and some other built-in features - like
>>> replicas).
>>> However I find (correct if I'm wrong) FreeIPA not very modular -
>> therefore
>>> I would like to know what's the strategy when deploying slave KDCs.
>>>
>>> I've seen this thread
>>> <https://www.redhat.com/archives/freeipa-users/2013-
>> September/msg00319.html>
>>> but I
>>> don't really want to have a replica - the idea was to deploy a separate
>> box
>>> only running KDC - since the authentication is delegated to RADIUS for
>>> Authentication, I don't need to expose LDAP Master to KDC slaves - If
>> yes,
>>> I would provide a read-only LDAP replica..
>>>
>>>
>>> For starters, where is the FreeIPA KDC stash file stored?
>>
>> AFAIK there is no prior art in setting up MIT KDC slaves. First of all,
>> FreeIPA does not use stash file and stores master key in LDAP instead.
>>
>> You can retrieve equivalent of stash file using following command:
>>
>> $ ipa-getkeytab --retrieve --principal K/M@ -k /tmp/stash.keytab
>> --binddn='cn=Directory manager' --bindpw=''
>>
>> *Make sure* that --retrieve option is present otherwise it will destroy
>> your
>> Kerberos database.
>>
>> The rest is up to your experimentation. I wish you good luck and please
>> report
>> your findings back to the mailing list!

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] DNS migration to FreeIPA and import of existing DNSSEC keys

[Petr Spacek]

On 17.8.2016 19:58, Guido Schmitz wrote:
> After some debugging, I found the error:
> 
>  cut =
> ipa : DEBUGstderr=
> ipa.ipapython.dnssec.bindmgr.BINDMgr: INFO attrs: {'idnsseckeyref':
> ['pkcs11:object=a1'], 'dn':
> 'cn=KSK-2014073634Z-a1,cn=keys,idnsname=myzone.com.,cn=dns,dc=int,dc=gtrs,dc=de',
> 'cn': ['KSK-2014073634Z-a1'], 'idnsseckeypublish':
> ['2014073634Z'], 'objectclass': ['idnsSecKey'], 'idnsseckeysep':
> ['TRUE'], 'idnssecalgorithm': ['RSASHA1NSEC3SHA1'], 'idnsseckeyzone':
> ['TRUE'], 'idnsseckeycreated': ['2014073634Z'],
> 'idnsseckeyactivate': ['2014073634Z']}
> ipa : DEBUGStarting external process
> ipa : DEBUGargs=/usr/sbin/dnssec-keyfromlabel-pkcs11 -K
> /var/named/dyndb-ldap/ipa/master/myzone.com/tmp5dI2FC -a
> RSASHA1NSEC3SHA1 -l
> pkcs11:object=a1;pin-source=/var/lib/ipa/dnssec/softhsm_pin -I none
> -D none -P 2014073634 -A 2014073634 -f KSK myzone.com.
> ipa : DEBUGProcess finished, return code=1
> ipa : DEBUGstdout=
> ipa : DEBUGstderr=dnssec-keyfromlabel: fatal: unknown
> algorithm RSASHA1NSEC3SHA1
> 
> Traceback (most recent call last):
>   File "/usr/libexec/ipa/ipa-dnskeysyncd", line 112, in 
> while ldap_connection.syncrepl_poll(all=1, msgid=ldap_search):
>   File "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 409,
> in syncrepl_poll
> self.syncrepl_refreshdone()
>   File "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py",
> line 118, in syncrepl_refreshdone
> self.bindmgr.sync(self.dnssec_zones)
>   File "/usr/lib/python2.7/site-packages/ipapython/dnssec/bindmgr.py",
> line 209, in sync
> self.sync_zone(zone)
>   File "/usr/lib/python2.7/site-packages/ipapython/dnssec/bindmgr.py",
> line 182, in sync_zone
> self.install_key(zone, uuid, attrs, tempdir)
>   File "/usr/lib/python2.7/site-packages/ipapython/dnssec/bindmgr.py",
> line 117, in install_key
> result = ipautil.run(cmd, capture_output=True)
>   File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line
> 479, in run
> raise CalledProcessError(p.returncode, arg_string, str(output))
> subprocess.CalledProcessError: Command
> '/usr/sbin/dnssec-keyfromlabel-pkcs11 -K
> /var/named/dyndb-ldap/ipa/master/myzone.com/tmp5dI2FC -a
> RSASHA1NSEC3SHA1 -l
> pkcs11:object=a1;pin-source=/var/lib/ipa/dnssec/softhsm_pin -I none
> -D none -P 2014073634 -A 2014073634 -f KSK myzone.com.' returned
> non-zero exit status 1
>  cut =
> 
> dnssec-keyfromlabel-pkcs11 expects NSEC3RSASHA1 for algorithm 7, but it
> gets RSASHA1NSEC3SHA1 instead (just the plain attribute value from LDAP).
> 
> I've changed a few lines in
> /usr/lib/python2.7/site-packages/ipapython/dnssec/bindmgr.py in method
> install_key:
> 
>  cut 
> 108c108,112
> < cmd = [paths.DNSSEC_KEYFROMLABEL, '-K', workdir, '-a',
> attrs['idnsSecAlgorithm'][0], '-l', uri]
> ---
>> algo = attrs['idnsSecAlgorithm'][0]
>> if algo == 'RSASHA1NSEC3SHA1':
>>  algo = 'NSEC3RSASHA1'
>> cmd = [paths.DNSSEC_KEYFROMLABEL, '-K', workdir, '-a', algo,
> '-l', uri]
>  cut 
> 
> Now, everything seems to work correctly: The DNSKEY records are
> published with the correct algorithms and the ZSK is signed by both KSKs
> (the imported one and the IPA generated one).

I'm glad it finally works!

For this particular problem I've created ticket
https://fedorahosted.org/freeipa/ticket/6229
so we can fix it independently on key import feature.

Thank you *very* much for your effort, it is very valuable experience and it
will help to improve FreeIPA!

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] DNS migration to FreeIPA and import of existing DNSSEC keys

[Petr Spacek]

On 17.8.2016 14:38, Guido Schmitz wrote:
>>> Still, there is one problem:
>>> My old KSK uses algorithm 7 (RSASHA1NSEC3SHA1) and IPA (by default) uses
>>> algorithm 8 (RSASHA256). The old key is correctly marked as algorithm 7
>>> in LDAP (under attribute idnsSecAlgorithm in the entry
>>> cn=KSK-timestamp-id,cn=keys,idnsname=myzone.com,cn=dns), but BIND seems
>>> to ignore this attribute and assumes that it is always algorithm 8.
>>
>> Hmm, algorithm mismatch will cause DNSSEC validation to break horribly. The
>> generated records will not match what is indicated in DS record of the parent
>> zone...
>>
>> Please look into
>> /var/named/dyndb-ldap/ipa/master/myzone.com/keys
>> and inspect BIND key files (*.private). Cross-check values in files with
>> values shown by OpenDNSSEC. All the values should match.
>>
>> If they do not match, we have a bug somewhere in the synchronization
>> mechanism, which is possible.
> 
> The imported KSK does not exist in this directory (neither on the master
> server nor on the replica). The keys created by IPA are present in this
> directory.
> 
> Now, I also checked, if the imported KSK is used to sign the ZSK, but
> there are no matching RRSIG records. (When I wrote earlier that BIND
> uses the imported KSK, I only checked whether a DNSKEY record for this
> KSK is present. The DNSKEY record is present, but with the wrong algorithm.)

Okay, so we need to go back to see where the problem is.

Part A - key material:
0. I assume that you double-checked key attributes in OpenDNSSEC.

1. ipa-ods-exporter service on IPA DNSSEC key master server should not report
any errors when exporting keys (triggered by ods-signer ipa-full-update)

2. Output of these two commands should match:
all IPA DNS servers$ \
python2 /usr/lib/python2.*/site-packages/ipapython/dnssec/localhsm.py

any IPA DNS server$ \
python2 /usr/lib/python2.*/site-packages/ipapython/dnssec/ldapkeydb.py

This verifies that key material was replicated correctly.


Part B - key metadata:
These are read by ipa-dnskeysyncd daemon from LDAP and stored in BIND key files.

Please check logs of ipa-dnskeysyncd service and watch out for errors.
debug=True in /etc/default.conf will tell you more if needed.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] named-pkcs11 doesn't start after bind update

[Petr Spacek]

On 17.8.2016 09:52, Arthur Fayzullin wrote:
> any news?

Not really, we are waiting for SELinux policy maintainers to pick this up.

For the time being, you can try this:
1. Switch to permissive mode
$ setenforce 0

2. Watch audit log for new AVCs:
$ tail -f /var/log/audit.log | grep AVC > /tmp/avcs.log

3. Restart the named-pkcs11 service
$ systemctl restart named-pkcs11

4. Generate missing rules:
$ audit2allow /tmp/avcs.log

5. Review the rules and load the if necessary

Please post the resulting  /tmp/avcs.log and rules to the bug
https://bugzilla.redhat.com/show_bug.cgi?id=1357665
to speed things up.

Thank you!
Petr^2 Spacek

> I've tried to make selinux permissive and write new policy,
> that didn't help.
> 
> require {
> type ipa_var_lib_t;
> type named_t;
> class dir read;
> class file { write open lock read getattr };
> }
> 
> #= named_t ==
> allow named_t ipa_var_lib_t:dir read;
> allow named_t ipa_var_lib_t:file { write open lock read getattr };
> 
> 
> 22.07.2016 13:04, Roberto Cornacchia пишет:
>> Ben and Petr,
>>
>> Thanks for your inputs, I'll keep an eye on those bug reports.
>>
>> Roberto
>>
>> On 22 July 2016 at 09:51, Petr Spacek <pspa...@redhat.com
>> <mailto:pspa...@redhat.com>> wrote:
>>
>> On 22.7.2016 04:43, Ben Lipton wrote:
>> > I'm not familiar enough with Fedora release engineering to know
>> how this gets
>> > fixed permanently, but I'll share some investigation I've done.
>> >
>> > This appears to be due to a change in the
>> selinux-policy-targeted package that
>> > happened recently. As of the latest version, named-pkcs11 tries
>> to run as type
>> > named_t instead of unconfined_service_t, but it isn't allowed to
>> read the
>> > files from IPA [1]. When I downgraded to the selinux-policy and
>> > selinux-policy-targeted packages from [2] I was able to start
>> named-pkcs11, so
>> > that might be a workaround you can use for now. Ultimately, the
>> patch that
>> > fixes [3] might need to be backported to F23.
>>
>> This is being tracked as
>> https://bugzilla.redhat.com/show_bug.cgi?id=1357665
>>
>> Stay tuned.
>>
>> Petr^2 Spacek
>>
>> >
>> > Ben
>> >
>> > [1]
>> > 
>> > time->Fri Jul 22 04:17:44 2016
>> > type=AVC msg=audit(1469153864.756:705): avc:  denied  { read }
>> for pid=11616
>> > comm="named-pkcs11" name="tokens" dev="dm-0" ino=26318195
>> > scontext=system_u:system_r:named_t:s0
>> > tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=dir
>> permissive=1
>> > 
>> > time->Fri Jul 22 04:17:44 2016
>> > type=AVC msg=audit(1469153864.756:706): avc:  denied  { getattr
>> } for
>> > pid=11616 comm="named-pkcs11"
>> >
>> 
>> path="/var/lib/ipa/dnssec/tokens/12cfb199-b2fe-d328-0b3a-e644756b73d6/token.object"
>> > dev="dm-0" ino=609982 scontext=system_u:system_r:named_t:s0
>> > tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=file
>> permissive=1
>> > 
>> > time->Fri Jul 22 04:17:44 2016
>> > type=AVC msg=audit(1469153864.756:707): avc:  denied  { read
>> write } for
>> > pid=11616 comm="named-pkcs11" name="generation" dev="dm-0"
>> ino=731584
>> > scontext=system_u:system_r:named_t:s0
>> > tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=file
>> permissive=1
>> > 
>> > time->Fri Jul 22 04:17:44 2016
>> > type=AVC msg=audit(1469153864.757:708): avc:  denied  { open }
>> for pid=11616
>> > comm="named-pkcs11"
>> >
>> 
>> path="/var/lib/ipa/dnssec/tokens/12cfb199-b2fe-d328-0b3a-e644756b73d6/generation"
>> > dev="dm-0" ino=731584 scontext=system_u:system_r:named_t:s0
>> > tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=file
>> permissive=1
>> > 
>> > time->Fri Jul 22 04:17:44 2016
>> > type=AVC msg=audit(1469153864.757:709): avc:  denied  { lock }
>> for pid=11616
>> > comm="named-pkcs11"
>> >
>> 
>> path="/var/lib/ipa/dnssec/tokens/12cfb199-b2fe-d328-0b3

[Freeipa-users] Announcing bind-dyndb-ldap version 10.1

[Petr Spacek]

The FreeIPA team is proud to announce bind-dyndb-ldap version 10.1.

It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/

The new version has also been built for Fedora 24+:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-ea30aafae1


Latest news:

10.1

[1] Prevent crash while reloading previously invalid but now valid DNS zone.
https://fedorahosted.org/bind-dyndb-ldap/ticket/166

[2] Fix zone removal to respect forward configuration inheritance.
https://fedorahosted.org/bind-dyndb-ldap/ticket/167

10.0

[1] Default TTL can be configured at zone level in dNSdefaultTTL attribute.
Please note that changes may not be applied until server reload.
https://fedorahosted.org/bind-dyndb-ldap/ticket/70

[2] Certain subset of configuration options can be specified
in idnsServerConfigObject in LDAP. Each bind-dyndb-ldap instance will
only use values from object with idnsServerId attribute matching server_id
configured in named.conf. This can be used for per-server configuration
in shared LDAP tree.
https://fedorahosted.org/bind-dyndb-ldap/ticket/162

[2] fake_mname option can be specified in idnsServerConfigObject in LDAP.
Please note that changes may not be applied until server reload.
https://fedorahosted.org/bind-dyndb-ldap/ticket/162

[3] Per-server global forwarders can be configured in idnsServerConfigObject.
https://fedorahosted.org/bind-dyndb-ldap/ticket/162

[4] Dynamic record generation using idnsTemplateObject and
idnsSubstitutionVariable;ipalocation attribute from idnsServerConfigObject
is supported. Please see README.
Please note that changes may not be applied until server reload.
https://fedorahosted.org/bind-dyndb-ldap/ticket/126

[5] Forwarding configuration is properly ignored for disabled master zones.

[6] Interaction between DNS root zone and global forwarding is now
deterministic and root zone has higher priority over global forwarding.

[7] Various problems in internal event processing were fixed.

[8] Potential crash in early start-up phase was fixed.

[9] Compatibility with BIND >= 9.10.4b1 was improved


== Upgrading ==
A server can be upgraded by installing updated RPM. BIND has to be restarted
manually after the RPM installation.

Downgrading back to any 9.x version is supported as long as new features are
not used.

FreeIPA users have to upgrade to version 10.0 or newer before enabling 'DNS
locations' feature in FreeIPA.


== Advance notification: Limited compatibility with BIND 9 ==
Please note that bind-dyndb-ldap 10.x is the last branch compatible with
BIND 9.10 or older.

bind-dyndb-ldap version 11.0 will be compatible only with BIND 9.11 and newer.
At the same time, version 11.0 will introduce incompatible changes to
configuration format.


== Feedback ==
Please provide comments, report bugs, and send any other feedback via the
freeipa-users mailing list:
http://www.redhat.com/mailman/listinfo/freeipa-users

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] DNS migration to FreeIPA and import of existing DNSSEC keys

[Petr Spacek]

On 16.8.2016 14:48, Guido Schmitz wrote:
>>
>> Any tool which can do key import from file into PKCS#11 token should work, in
>> theory.
> 
> I've tried pkcs11-tool from the OpenSC project and p11tool from GnuTLS.
> p11tool seems to be able to take some (undocumented?) flags from the
> command line when importing, but p11tool does not seem to work with
> SoftHSM. So I've tried the procedure you suggested:
> 
>>
>> If you do not find any such tool, it will be easiest to patch softhsm2-util 
>> to
>> set the flag to TRUE on import. I'm attaching quick and dirty patch which
>> should do the job (for softhsm compiled against OpenSSL).
>>
>> 1. Get the sources:
>> $ git clone https://github.com/opendnssec/SoftHSMv2.git
>>
>> 2. Apply the patch:
>> git am 0001-HACK-for-OpenSSL-version-import-all-keys-with-CKA_EX.patch
>>
>> 3. Use how-to
>> https://github.com/opendnssec/SoftHSMv2/#installation
>> to compile the tool.
>>
>> 4. You do not need to install the library into system paths, just execute the
>> softhsm2-util binary from the build directory to do import and use standard
>> library as before.
>>
>> I hope it will help. Please let me know your findings so I can submit 
>> improved
>> patch upstream (if we were successful).
>>
> 
> Your patch was not sufficient enough. I've added a patch (to be applied
> on top of your patch), which extends your patch to set the extractable flag.

Ah, I see! I modified the wrong table, thank you for noticing that.

> Now, after a new import, the keys are indeed marked as extractable in
> SoftHSM and (automatically) copied into the LDAP subtree
> cn=keys,cn=sec,cn=dns.
> 
> I've noticed that the following flags of the keys still differ in the
> output of "python2
> /usr/lib/python2.*/site-packages/ipapython/dnssec/localhsm.py":
> 'ipk11alwayssensitive': True for keys generated by IPA, False for
> imported keys
> 'ipk11local': True for keys generated by IPA, False for imported keys

These two should not make any difference in our case. (They indicate that the
keys were not created inside the HSM in question and could possibly be exposed
in plain text somewhere.)

> I do not know, if these flags are important for the whole process to
> work, but I also do not know how to set these flags.
> 
> The imported keys are still not used by BIND: The keys are not added to
> the zone subtree (cn=keys,idnsname=myzone.com,cn=dns) in LDAP, but the
> command "sudo -u ods SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf
> ods-ksmutil key list --verbose" shows, that the newly imported key (I've
> carried out tests only with the KSK so far) is assigned to the zone and
> is in state "active".

Now it is getting interesting :-)

First of all, what version of FreeIPA packages and on what distro are you
using? There are significant differences between package versions.

The export is handled by ipa-ods-exporter service on IPA DNSSEC key master
server. Look at its logs and see if it reports any errors.

I'm not sure how OpenDNSSEC handles key import. IPA is waiting on OpenDNSSEC
signer's socket for events which indicate key state change. If this does not
happen the key is not exported.

You can trigger this manually by calling command
"ods-signer ipa-full-update"
or
"ods-signer update "

Watch the ipa-ods-exporter service logs when you run this command and watch
out for any problems. You might add debug=True to /etc/ipa/default.conf if you
need to see more details about the process.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Limited "self" registration to IPA and an IPA group

[Petr Spacek]

On 16.8.2016 00:34, Steven Jones wrote:
> Hi,
> 
> 
> I have a request to do limited automatic/self provisioning of users 
> provisioning to specifc server.  The idea is a lecturer would setup students  
> into IPA and select a specific user group from a limited drop down menu.
> 
> 
> Is this possible to do such provisioning a very tied down / limited access 
> with the std IPA or would that need a custom web page/ application into the 
> API (or what ever)?

FreeIPA currently does not have pre-baked user interface to do this.

If you really want, it should be possible manually tune IPA permissions (or
LDAP Access Control Instructions directly) to do what you are asking for.

If you decide to implement this, feel free to ask this list - we will try to
help you.


If you don't implement this youself, you can use
https://fedorahosted.org/freeipa/ticket/5876
for tracking purposes.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] KDC returned error string: NOT_ALLOWED_TO_DELEGATE

[Petr Spacek]

On 15.8.2016 20:18, Linov Suresh wrote:
> We have IPA replica set up in RHEL 6.4 and is FreeIPA 3.0.0
> 
> 
> We can only add the clients from IPA Server 01, not from IPA Server 02.
> When I tried to add the client from IPA Server 02, getting the error,
> 
> 
> ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI Error:
> Unspecified GSS failure.  Minor code may provide more information (KDC
> returned error string: NOT_ALLOWED_TO_DELEGATE)
> 
> SASL/GSSAPI authentication started
> 
> SASL username: vp...@example.net
> 
> SASL SSF: 56
> 
> SASL data security layer installed.
> 
> ldap_modify: No such object (32)
> 
> additional info: Range Check error
> 
> modifying entry "fqdn=cpe-5061747522f9.example.net
> ,cn=computers,cn=accounts,dc=example,dc=net"
> 
> 
> Could you please help us to fix this?

We need to see exact steps you did before we can give you any meaningful advice.

Please have a look at
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

It is a very nice document which describes general bug reporting procedure and
best practices.

We will certainly have a look but we need first see the information :-)

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Original java script I ahave been TRYING to modify to use the flatness that is IPA.

[Petr Spacek]

On 15.8.2016 19:45, Michael Sean Conley wrote:
> 
> Hey gang, so this is the original file I was using to get us hooked in via
> LDAPS for the webpage.
> Note - it has OU's instead of CN's,
> 
> Anyway, I'm still at a loss.
> 
> What do you folks think?
> 
> 
>   
>  className="org.apache.karaf.jaas.modules.ldap.LDAPLoginModule"
>  flags="required">
>   initialContextFactory=com.sun.jndi.ldap.LdapCtxFactory
>   connection.username=cn=Directory Manager
>   connection.password=password
>   connection.url=ldaps://aba-ldap.aba.house.com:636
>   user.base.dn=ou=ApplicationUsers,ou=People,dc=aba,dc=house,dc=com
>   user.filter=(uid=%u)
>   user.search.subtree=true
>   role.base.dn=ou=JBoss,ou=Roles,dc=aba,dc=house,dc=com
>   role.name.attribute=cn
>   role.filter=
> (member=uid=%u,ou=ApplicationUsers,ou=People,dc=aba,dc=house,dc=com)
>   role.search.subtree=true
>   role.mapping=admin=group,admin,manager,viewer,webconsole
>   authentication=simple
>   ssl.protocol=SSL
>   ssl.truststore=truststore
>   ssl.algorithm=PKIX
> 
>   
> 
>path="file:${javax.net.ssl.trustStore}"
> keystorePassword="${javax.net.ssl.trustStorePassword}" />
> 
> 

Hi,

Rob already replied to your previous e-mail with probable cause:

>>initialContextFactory=com.sun.jndi.ldap.LdapCtxFactory
>>connection.username=cn=ddfusr
>>connection.password=iloveaba!
>>connection.url=ldaps://aba-idam.aba.house.com:636
>>user.base.dn=cn=users,cn=accounts,dc=aba,dc=house,dc=com
>>user.filter=(uid=%u)
>>user.search.subtree=true
>>role.base.dn=cn=JBoss,cn=users,cn=accounts,dc=aba,dc=house,dc=com
>>role.name.attribute=cn
>>
>> role.filter=(member=uid=%u,cn=users,cn=accounts,dc=aba,dc=house,dc=com)
>>role.search.subtree=true
>>role.mapping=admin=group,admin,manager,viewer,webconsole
>>authentication=simple
>>ssl.protocol=SSL
>>ssl.truststore=truststore
>>ssl.algorithm=PKIX
>>  
>>
>>
>> and I tried to log in with the ddfusr account and
>>
>> Error 32.
>
> You're still using the wrong user to bind. There is no cn=ddfusr. At
> best there is a uid=ddfusr if the user.base is automatically added
> (which it probably isn't).
>
> It probably needs to be
> uid=ddfusr,cn=users,cn=accounts,dc=aba,dc=home,dc=com just like in the
> ldapsearch.
>
> rob

I would start with fixing connection.username so it points to an actual user
object in LDAP.

It is hard to advise something else because I'm not familiar with the
software. If you have some documentation for the LDAPLogin module I can have a
look but a quick google query did not turn up docs to me.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Troubleshooting Forest-Trust to AD

[Petr Spacek]

On 12.8.2016 02:18, Paul Smith wrote:
> I'm having issues establishing Trust with an existing Active Directory
> domain (Windows Server 2012 R2). I can get IPA up and running and have
> spent the day troubleshooting DNS\Kerberos
> 
> I think the main issue is something remaining in kerberos but i'm not sure
> what.
> I followed the deployment and troubleshooting guide as best I could with my
> environment.
> The problem happens when I try the ipa trust-add. I get a message:
> ipa: ERROR: AD domain controller complains about communication sequence
> 
> I know that my time zone and time is in sync with the same server.
> This is a proof-of-concept design that I'd like to explore\learn more
> about. Below are details on the linux environment:
> 
> *uname -a*
> Linux dclinux.linuxtrust.local 4.4.0-34-generic #53-Ubuntu SMP Wed Jul 27
> 16:06:39 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> 
> *lsb_release -a*
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 16.04.1 LTS
> Release:16.04
> Codename:   xenial
> 
> *ipa --version*
> VERSION: 4.3.1, API_VERSION: 2.164
> 
> If anyone can help, I'd be more than willing to post the detailed samba
> logs, as this is just a local lab environment

I would recommend you to start with
http://www.freeipa.org/page/Troubleshooting#Trusts

:-)

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] DNS migration to FreeIPA and import of existing DNSSEC keys

[Petr Spacek]

On 15.8.2016 12:14, Guido Schmitz wrote:
> On 12.08.2016 13:58, Petr Spacek wrote:
>> On 12.8.2016 13:26, Guido Schmitz wrote:
>>> Hi!
>>>
>>> I want to migrate my existing DNS setup to FreeIPA. As this existing
>>> setup already uses DNSSEC, I want to import my current DNSSEC keys into
>>> FreeIPA to have a smooth transition over to IPA's DNS. (The authorative
>>> DNS servers for the zones are set up as slaves that get the zone via
>>> AXFR and can seamlessly switch to AXFR from IPA.)
>>>
>>> In my test migration, I have created the DNS zone I want to migrate in
>>> FreeIPA and have enabled DNSSEC.
>>>
>>> As far as I understand IPA's implementation of DNSSEC, OpenDNSSEC takes
>>> care of key management and key rollover [1]. Hence, I have imported my
>>> existing DNSSEC keys to OpenDNSSEC according to OpenDNSSEC's HOWTO [2]
>>> and OpenDNSSEC correctly shows the imported keys along with the DNSSEC
>>> keys generated by IPA.
>>>
>>> I thought that ipa-dnskeysyncd would take care of syncing the keys from
>>> OpenDNSSEC to 389 LDAP, but this does not happen: In 389 LDAP, only the
>>> keys initially created by IPA (while enabling DNSSEC for this zone)
>>> exist and hence, only these keys are used to sign the zone.
>>>
>>> Do I need to manually insert my existing DNSSEC keys into the LDAP or
>>> take some other additional steps?
>>
>> Hello!
>>
>> In theory ipa-dnskeysyncd should take care of it. The important step is to
>> ensure that all the imported keys have CKA_EXTRACTABLE PKCS#11 flag (in
>> SoftHSM) set to TRUE otherwise the synchronization will not work.
> 
> That seems to be my problem: The CKA_EXTRACTABLE flag is not set on the
> imported keys. I do not have any clue on how to set this flag.
> 
> I have used the following command to import the keys:
> 
> sudo -u ods SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf softhsm2-util
> --import ksk.pem --slot 0 --pin *PIN* --label ipaDNSSEC --id *ID*
> 
> softhsm2-util does not seem to have any parameter to set the
> CKA_EXTRACTABLE flag.
> 
> Are there other ways to import keys into the SoftHSM that allow setting
> this flag?

Any tool which can do key import from file into PKCS#11 token should work, in
theory.

If you do not find any such tool, it will be easiest to patch softhsm2-util to
set the flag to TRUE on import. I'm attaching quick and dirty patch which
should do the job (for softhsm compiled against OpenSSL).

1. Get the sources:
$ git clone https://github.com/opendnssec/SoftHSMv2.git

2. Apply the patch:
git am 0001-HACK-for-OpenSSL-version-import-all-keys-with-CKA_EX.patch

3. Use how-to
https://github.com/opendnssec/SoftHSMv2/#installation
to compile the tool.

4. You do not need to install the library into system paths, just execute the
softhsm2-util binary from the build directory to do import and use standard
library as before.

I hope it will help. Please let me know your findings so I can submit improved
patch upstream (if we were successful).

> Or is there a possibility to modify the flag later (although
> this would be contrary to the idea of an "HSM")?

It is not possible to change it after object creation for the reasons stated
above.

Petr^2 Spacek

> 
> 
> -Guido
> 
> 
> 
>>
>> Please note that we never tested this so following text is just untested 
>> theory:
>>
>> Start with usual DNSSEC debugging for FreeIPA:
>> http://www.freeipa.org/page/Troubleshooting#DNSSEC_signing_does_not_work
>>
>> Besides all other things, I would double-check that (on FreeIPA DNSSEC key
>> master server):
>> 1) ods-ksmutil key list --verbose
>> shows the imported keys in state active or publish
>>
>> 2) Command
>> python2 /usr/lib/python2.*/site-packages/ipapython/dnssec/localhsm.py
>> shows that keys are CKA_EXTRACTABLE.
>>
>> 3) If all of the above seems to be okay, check logs for ipa-dnskeysyncd and
>> ipa-ods-exporter services:
>> journalctl -u ipa-dnskeysyncd -u ipa-ods-exporter
>>
>> ipa-ods-exporter is the piece doing dirty export work.
>>
>> I hope it helps.
>>
>> Petr^2 Spacek
>>
>>
>>>
>>> Cheers,
>>> -Guido
>>>
>>>
>>>
>>> [1] https://www.freeipa.org/page/V4/DNSSEC_Support#Implementation
>>> [2] https://wiki.opendnssec.org/display/DOCS/Migrating+to+OpenDNSSEC
From aaf7a47f2d45d8b4f170a386a48898dae26e71b7 Mon Sep 17 00:00:00 2001
From: Petr Spacek <pspa...@redhat.com>
Date: Mon, 15 Aug 2016 13:41:38 +0200
Subject: [PATCH] HACK for OpenSSL version: import all keys with
 CKA_E

Re: [Freeipa-users] freeipa server capacity planning

[Petr Spacek]

On 13.8.2016 13:00, Rakesh Rajasekharan wrote:
> Hi,
> 
> I have successfully running freeipa setup across my envs.. and now planning
> to move it to one of the prod envs where we have around 4000 clients.

The most important characteristics to consider is: What the clients do?

Do they cache intelligently (e.g. using SSSD)? If it is the case then your
config should be fine.

Are they 'dumb' and do LDAP operations all the time? Then you can face
problems even with smaller number of clients, it depends.

Sorry for nor having better answer.

Petr^2 Spacek


> I am running a single IPA server instance with regular backups being taken
> to handle any disasters
> 
> Are there any recommendations on the system configuration, I am using a 4
> CPU, 30GB Ram machine. will that be ok or should I upgrade to a higher
> configuration
> 
> Also, the default File descriptors is set to 8192 by IPA, with the number
> of clients does it make sense to increase the value of
> nsslapd-maxdescriptors.

I do not know myself, please try to look up answer in
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Performance_Tuning_Guide/index.html

Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Does FreeIPA require ICMP to be allowed? Can it cause login speed issues?

[Petr Spacek]

On 12.8.2016 22:03, Jake wrote:
> Hey Guys, 
> Can anyone tell me if there are issues caused by blocking ICMP requests 
> between ipa clients, ipa servers and ad servers? 

For IPv4:
In theory, if your network is in ideal state and no service ever goes down
(unrealistic), it should work.

In practice, you will be observing long timeouts from time to time because the
clients will not be able to immediately detect that a service is down and
quickly fail-over to another server.


For IPv6: The network will totally break.


> We typically filter ICMP between all systems.
> 
> Also, if anyone has good documentation as to what ports are required between 
> each I'd really appreciate it! 
> 
>>From IPA Server to AD Server (trust) 
>>From IPA Client to IPA Server 
>>From IPA Client to AD Server (if any, unsure if kerberos/ldap is needed here 
>>or not on v4) 
>>From AD Client to IPA Client (ad users on windows machines accessing ipa 
>>client over ssh with kerberos gssapi) 

For IPA servers, please see
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#prereq-ports

For IPA clients, please see
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/clients-prereqs.html#prereq-ports-clients

For AD trusts, please see
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-requirements.html#trust-req-ports


IPA & AD clients in cross-forest trust need to be able to communicate with IPA
and AD servers at least for Kerberos, but I would not bother with filtering
these specifically. Take them as clients joined to both realms.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Unable to set up freeIPA on a fresh ubuntu 16.04.1 install

[Petr Spacek]

On 15.8.2016 03:29, David Kowis wrote:
> On 08/14/2016 07:57 PM, David Kowis wrote:
>> On 08/14/2016 02:31 PM, David Kowis wrote:
>>> Perhaps someone else has had this error before, or maybe just knows what
>>> I need to do?
>>
>> Digging through the mailing list, I only find this guy:
>> https://www.redhat.com/archives/freeipa-devel/2014-October/msg00480.html
>>
>> Seems someone had the exact same problem I did almost two years ago, and
>> didn't post about their solution, if they got any solution.
> 
> Narrowed it down a bit further:
> 
> 
> Aug 14 20:27:24 freeipavm ipa-dnskeysyncd[31211]: ipa: WARNING: session
> memcached servers not running
> Aug 14 20:27:26 freeipavm ipa-dnskeysyncd[31211]: ipa : INFO
> LDAP bind...
> Aug 14 20:27:26 freeipavm ipa-dnskeysyncd[31211]: Traceback (most recent
> call last):
> Aug 14 20:27:26 freeipavm ipa-dnskeysyncd[31211]:   File
> "/usr/lib/ipa/ipa-dnskeysyncd", line 92, in 
> Aug 14 20:27:26 freeipavm ipa-dnskeysyncd[31211]:
> ldap_connection.sasl_interactive_bind_s("", ipaldap.SASL_GSSAPI)
> Aug 14 20:27:26 freeipavm ipa-dnskeysyncd[31211]:   File
> "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 932, in
> sasl_interactive_bind_s
> Aug 14 20:27:26 freeipavm ipa-dnskeysyncd[31211]: res =
> self._apply_method_s(SimpleLDAPObject.sasl_interactive_bind_s,*args,**kwargs)
> Aug 14 20:27:26 freeipavm ipa-dnskeysyncd[31211]:   File
> "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 900, in
> _apply_method_s
> Aug 14 20:27:26 freeipavm ipa-dnskeysyncd[31211]: return
> func(self,*args,**kwargs)
> Aug 14 20:27:26 freeipavm ipa-dnskeysyncd[31211]:   File
> "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 244, in
> sasl_interactive_bind_s
> Aug 14 20:27:26 freeipavm ipa-dnskeysyncd[31211]: return
> self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags)
> Aug 14 20:27:26 freeipavm ipa-dnskeysyncd[31211]:   File
> "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 106, in
> _ldap_call
> Aug 14 20:27:26 freeipavm ipa-dnskeysyncd[31211]: result =
> func(*args,**kwargs)
> Aug 14 20:27:26 freeipavm ipa-dnskeysyncd[31211]:
> ldap.STRONG_AUTH_NOT_SUPPORTED: {'info': 'sasl mechanism not supported',
> 'desc': 'Authentication method not supported'}
> Aug 14 20:27:26 freeipavm systemd[1]: ipa-dnskeysyncd.service: Main
> process exited, code=exited, status=1/FAILURE
> Aug 14 20:27:26 freeipavm systemd[1]: ipa-dnskeysyncd.service: Unit
> entered failed state.
> Aug 14 20:27:26 freeipavm systemd[1]: ipa-dnskeysyncd.service: Failed
> with result 'exit-code'.
> 
> 
> Seems this service doesn't start with the sasl mechanism not supported.
> 
> Does anyone know what's missing, or how I can get further information?
> Is it the LDAP server, or am I missing a sasl lib for python? Maybe a
> configuration file?


This is weird as LDAP SASL & GSSAPI is pretty standard thing.

In any case, you can check server logs or use tcpdump/wireshark and see if the
error somes from LDAP server or if it is client side error.

That would tell us where to focus.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ldaps Java script issues with RH IdM - odd that I cannot make it connect...

[Petr Spacek]

On 12.8.2016 19:13, Michael Sean Conley wrote:
> role.filter=
> (member=uid=%u,cn=users,cn=accounts,dc=aba,dc=house,dc=com)

I suspect that this filter is incorrect. Likely, it should be only
"(uid=%u,cn=users,cn=accounts,dc=aba,dc=house,dc=com)".

I hope it helps.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] DNS migration to FreeIPA and import of existing DNSSEC keys

[Petr Spacek]

On 12.8.2016 13:58, Petr Spacek wrote:
> On 12.8.2016 13:26, Guido Schmitz wrote:
>> Hi!
>>
>> I want to migrate my existing DNS setup to FreeIPA. As this existing
>> setup already uses DNSSEC, I want to import my current DNSSEC keys into
>> FreeIPA to have a smooth transition over to IPA's DNS. (The authorative
>> DNS servers for the zones are set up as slaves that get the zone via
>> AXFR and can seamlessly switch to AXFR from IPA.)
>>
>> In my test migration, I have created the DNS zone I want to migrate in
>> FreeIPA and have enabled DNSSEC.
>>
>> As far as I understand IPA's implementation of DNSSEC, OpenDNSSEC takes
>> care of key management and key rollover [1]. Hence, I have imported my
>> existing DNSSEC keys to OpenDNSSEC according to OpenDNSSEC's HOWTO [2]
>> and OpenDNSSEC correctly shows the imported keys along with the DNSSEC
>> keys generated by IPA.
>>
>> I thought that ipa-dnskeysyncd would take care of syncing the keys from
>> OpenDNSSEC to 389 LDAP, but this does not happen: In 389 LDAP, only the
>> keys initially created by IPA (while enabling DNSSEC for this zone)
>> exist and hence, only these keys are used to sign the zone.
>>
>> Do I need to manually insert my existing DNSSEC keys into the LDAP or
>> take some other additional steps?
> 
> Hello!
> 
> In theory ipa-dnskeysyncd should take care of it. The important step is to
> ensure that all the imported keys have CKA_EXTRACTABLE PKCS#11 flag (in
> SoftHSM) set to TRUE otherwise the synchronization will not work.
> 
> Please note that we never tested this so following text is just untested 
> theory:
> 
> Start with usual DNSSEC debugging for FreeIPA:
> http://www.freeipa.org/page/Troubleshooting#DNSSEC_signing_does_not_work
> 
> Besides all other things, I would double-check that (on FreeIPA DNSSEC key
> master server):
> 1) ods-ksmutil key list --verbose
> shows the imported keys in state active or publish
> 
> 2) Command
> python2 /usr/lib/python2.*/site-packages/ipapython/dnssec/localhsm.py
> shows that keys are CKA_EXTRACTABLE.
> 
> 3) If all of the above seems to be okay, check logs for ipa-dnskeysyncd and
> ipa-ods-exporter services:
> journalctl -u ipa-dnskeysyncd -u ipa-ods-exporter
> 
> ipa-ods-exporter is the piece doing dirty export work.
> 
> I hope it helps.

Please note that on Fedora 24 you might be hitting this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1366640

> Petr^2 Spacek
> 
> 
>>
>> Cheers,
>> -Guido
>>
>>
>>
>> [1] https://www.freeipa.org/page/V4/DNSSEC_Support#Implementation
>> [2] https://wiki.opendnssec.org/display/DOCS/Migrating+to+OpenDNSSEC

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] DNS migration to FreeIPA and import of existing DNSSEC keys

[Petr Spacek]

On 12.8.2016 13:26, Guido Schmitz wrote:
> Hi!
> 
> I want to migrate my existing DNS setup to FreeIPA. As this existing
> setup already uses DNSSEC, I want to import my current DNSSEC keys into
> FreeIPA to have a smooth transition over to IPA's DNS. (The authorative
> DNS servers for the zones are set up as slaves that get the zone via
> AXFR and can seamlessly switch to AXFR from IPA.)
> 
> In my test migration, I have created the DNS zone I want to migrate in
> FreeIPA and have enabled DNSSEC.
> 
> As far as I understand IPA's implementation of DNSSEC, OpenDNSSEC takes
> care of key management and key rollover [1]. Hence, I have imported my
> existing DNSSEC keys to OpenDNSSEC according to OpenDNSSEC's HOWTO [2]
> and OpenDNSSEC correctly shows the imported keys along with the DNSSEC
> keys generated by IPA.
> 
> I thought that ipa-dnskeysyncd would take care of syncing the keys from
> OpenDNSSEC to 389 LDAP, but this does not happen: In 389 LDAP, only the
> keys initially created by IPA (while enabling DNSSEC for this zone)
> exist and hence, only these keys are used to sign the zone.
> 
> Do I need to manually insert my existing DNSSEC keys into the LDAP or
> take some other additional steps?

Hello!

In theory ipa-dnskeysyncd should take care of it. The important step is to
ensure that all the imported keys have CKA_EXTRACTABLE PKCS#11 flag (in
SoftHSM) set to TRUE otherwise the synchronization will not work.

Please note that we never tested this so following text is just untested theory:

Start with usual DNSSEC debugging for FreeIPA:
http://www.freeipa.org/page/Troubleshooting#DNSSEC_signing_does_not_work

Besides all other things, I would double-check that (on FreeIPA DNSSEC key
master server):
1) ods-ksmutil key list --verbose
shows the imported keys in state active or publish

2) Command
python2 /usr/lib/python2.*/site-packages/ipapython/dnssec/localhsm.py
shows that keys are CKA_EXTRACTABLE.

3) If all of the above seems to be okay, check logs for ipa-dnskeysyncd and
ipa-ods-exporter services:
journalctl -u ipa-dnskeysyncd -u ipa-ods-exporter

ipa-ods-exporter is the piece doing dirty export work.

I hope it helps.

Petr^2 Spacek


> 
> Cheers,
> -Guido
> 
> 
> 
> [1] https://www.freeipa.org/page/V4/DNSSEC_Support#Implementation
> [2] https://wiki.opendnssec.org/display/DOCS/Migrating+to+OpenDNSSEC
> 


-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Why is user status different on each master replica?

[Petr Spacek]

On 10.8.2016 17:19, Martin Basti wrote:
> 
> 
> On 09.08.2016 23:04, Larry Rosen wrote:
>>
>> This user was locked out due to Max Failure policy = 5
>>
>> If they’re supposed to be replicas, why the different status?
>>
>> [root@il10 ~]# ipa user-status  lramey
>>
>> ---
>>
>> Account disabled: False
>>
>> ---
>>
>>   Server: ipa-idm-01.ipajdr.local
>>
>>   Failed logins: 0
>>
>>   Last successful authentication: 20160808191857Z
>>
>>   Last failed authentication: 20160808191848Z
>>
>>   Time now: 2016-08-09T19:57:20Z
>>
>>   Server: ipa-idm-02.ipajdr.local
>>
>>   Failed logins: 5
>>
>>   Last successful authentication: 20160809151406Z
>>
>>   Last failed authentication: 20160809194741Z
>>
>>   Time now: 2016-08-09T19:57:21Z
>>
>> 
>>
>> Number of entries returned 2
>>
>>
>>
> Hi,
> 
> This is not replicated, because it may cause replication storms. So this
> status is local on each replica

Let me add that you can configure LDAP server to replicate this information:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication.html#Fractional_Replication

Of course, you will have to accept the performance penalty and higher risk of
replication conflicts.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA Session Management (WebUI, Kerberos, ...?)

[Petr Spacek]

On 9.8.2016 21:37, Joe Thielen wrote:
> First off, let me say THANK YOU to all of you who've helped make FreeIPA
> what it is.  I think it's a fantastic project and it's amazing what it has
> achieved.
> 
> Second off, I'm still quite new to FreeIPA, especially the internals.  This
> includes Kerberos.  I'm also very very limited at Python (I come from a PHP
> background - please don't hold it against me).  I have toyed around with
> LDAP a little bit before looking at FreeIPA.
> 
> After re-reading this e-mail I think it'd be important to note here at the
> top that my focus is on web-based apps and non-kerberized clients.  The web
> app server would be an IPA client.  I don't foresee a lot of terminal-based
> stuff going on, aside from potential admin CLI tasks (for the web-based
> app).
> 
> I apologize in advance for the length of this e-mail.  I have searched, a
> lot, to try and answer my own questions.  That's actually how I found
> FreeIPA in the first place.  I've looked at the site/wiki, the mailing list
> archive, and the Internet in general.  But I've been unable to find a
> solution, or suggestions, which achieves exactly what I'm looking for.  It
> may be that I'm just using the wrong terminology and/or getting lost in the
> buzzwords.
> 
> What I'm trying to figure out is if there is a way to centrally manage
> sessions, in addition to everything else FreeIPA currently does.  I'm not
> necessarily just talking about WebUI sessions, I'd like external web apps
> to be able to make use of it too.  And, I'd like to be able to manage them
> via the WebUI.
> 
> For example, let's say "joe" logs in to the WebUI (OR another web app tied
> to FreeIPA).  Now, on another computer, "admin" logs into the WebUI.  Can
> admin have a way to see that "joe" logged in, and, if need be, kill Joe's
> session?
> 
> I'd like for it to maintain history.  For each login/session, I'd like to
> see who logged in, when, from where, what their last access was, when they
> logged out (or if their session timed out), and the logout reason (manual
> logout, session timeout, or admin intervention).
> 
> But like I said, I'm not just looking for WebUI sessions.
> 
> Let's say I create a web app.  I put it on a machine which is an IPA
> client.  Thanks to the wealth of documentation and options, I have a
> variety of methods to achieve authentication.  FreeIPA makes this great,
> and for that I'm thankful.  However, in most of the documentation, it just
> says "create the session" cookie, and the rest is left as an exercise to
> the reader.  I'm familiar with web apps and have implemented session
> management before.  What I'd love to see is FreeIPA to be able to handle
> not just the auth but also the session management.
> 
> Why?  Because I'd not like to have to re-invent the wheel.  And I'm trying
> to see if there is already some method to do this that I'm just
> fundamentally missing.  Or at least if there are enough pieces that I could
> put together to make it happen.
> 
> For "fun", I've tried to set up auth using different methods.  I've
> successfully set it up using intercept_form_submit_module and
> lookup_identity_module.  That's pretty neat, works great for auth.  But, as
> far as I can tell, this method doesn't create a session or login trail in
> the memcached DB.  In fact, I can't really find any trail aside from the
> Kerberos logging messages in /var/log/krbkdc.log.
> 
> I've also used Tobias Sette's php-freeipa from GitHub.  That works great
> too... for auth.  And since that uses the JSON API, it looks like it does
> create a record in the memcached DB.  So I suppose this could be one way
> in, maybe by a FreeIPA plugin?
> 
> I guess I'm running in circles because then again I think... "what about
> pure Kerberos" clients...  or those using intercept_form_submit_module?
> I'm not familiar with PAM.  But from what I can tell, I assume there is a
> way to add a "pluggable" module for it too.  But on the server?  i.e., if a
> Kerberos session is established, is there a way, via PAM (or something
> else?) to log that session to the FreeIPA server?   I think this is kinda
> what Kerberos is trying to get away from, but for the use cases I'm
> thinking of, it'd be a big feature.  In my searching I've seen things like
> nss_mysql which look interesting, but of course wouldn't mesh with the
> FreeIPA WebUI memcached method.
> 
> Speaking of which, I know that memcached is not by any means a permanent
> session log, and I understand it's not intended to be.  So would this go
> into the LDAP tree?  Would this clog it up too much?  I'm looking to store
> a year of  info... or more depending on the scenario.
> 
> I've briefly looked at the Apache Shiro project.  I'm not a Java guy, but
> from I'm reading it kind of has the right idea.  It even notes that the
> session management portions can be accessed from other apps (on other
> machines) and not necessarily from Java.  But due to the whole thing being
> a 

Re: [Freeipa-users] FreeIPA and AD trusts on the same DNS domain

[Petr Spacek]

On 3.8.2016 22:22, Alston, David wrote:
> Greetings!
> 
>>> 2. Active Directory must never know anything about a DNS domain 
>>> freeipa.company.com (I'm not sure why)
>> Correct because if that happened then AD considers the whole subdomain as 
>> part of its realm and trust routing will not work.
> 
> Doesn't that mean that we have to have the FreeIPA servers on their own DNS 
> domain again?  So we can't have linux-server.company.com and 
> windows-server.company.com (managed by FreeIPA and AD respectively) because 
> there has to be a SOA for .company.com somewhere and that is already managed 
> by AD (in our environment).

The problem is not at DNS level but at Kerberos level. Anyway, this is in
depth described on
http://rhelblog.redhat.com/2016/07/13/i-really-cant-rename-my-hosts/

I hope it helps.
Petr^2 Spacek

> 
> --David Alston
> 
> 
> -Original Message-
> From: Simo Sorce [mailto:s...@redhat.com] 
> Sent: Wednesday, August 03, 2016 2:13 PM
> To: Alston, David
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] FreeIPA and AD trusts on the same DNS domain
> 
> On Wed, 2016-08-03 at 13:52 -0500, Alston, David wrote:
>> Greetings!
>>
>>  That sounds like great news!   Just to make sure I understand 
>> correctly..
>>
>> 1. Any server managed by FreeIPA must NEVER have had a computer object 
>> associated with them in AD?  (even if it has now been deleted)
> No, what a random server does or has done is irrelevant in this sense, but 
> see later, for caveats.
> 
>> 2. Active Directory must never know anything about a DNS domain 
>> freeipa.company.com (I'm not sure why)
> Correct because if that happened then AD considers the whole subdomain as 
> part of its realm and trust routing will not work.
> 
>> 3. My linux servers being managed by FreeIPA can still have the DNS 
>> domain company.com (instead of servername.freeipa.company.com)
> Although the strict answer is yes, if you put a linux server joined to 
> freeIPA in the AD DNS Domain then Single Sign On from Windows users will not 
> work, as AD will consider all request for tickets to those servers as 
> requests for itself and will never return referrals to the freeIPA KDCs for 
> those TGS requests, so clients will not be able to get tickets for those 
> servers. 
> 
>> 4. Single Signon to the Linux servers using AD credentials will still 
>> work
> 
> No, see above.
> 
>> 5. (BONUS) I could even let AD trust user accounts created in FreeIPA?
> 
> Not clear what you mean here. If you mean that IPA user accounts can operate 
> in the Windows domain, the answer is technicaly yes, although because we do 
> not expose (yet) a Global Catalog to the Windows AD servers, it will be hard 
> to set ACLs on the Windows side to actually authorize freeIPA users to login 
> to AD managed computers (it can probably be done via CLI, but not through AD 
> administrative UIs).
> We plan to fix this in the near future by providing a GC service.
> 
> 
> HTH,
> Simo.
> 
> --
> Simo Sorce * Red Hat, Inc * New York
> 
> 


-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] How to delete a managed group

[Petr Spacek]

On 3.8.2016 00:58, Bob Hinton wrote:
> Hi,
> 
> Something went wrong when trying to restore some preserved users so I
> deleted them and then tried to recreate them. This failed with -
> 
> ipa: ERROR: Unable to create private group. A group 'X'  already exists.
> 
> Trying to delete this group produces -
> 
> ipa: ERROR: Unable to create private group. A group 'X' already exists.
> 
> Trying to detach it with
> 
> ipa group-detach X
> 
> produces
> 
> ipa: ERROR: X: group not found
> 
> ipa group-show X

I would try
$ ipa group show X --all --raw

that could show us if there is something interesting like replication conflict
or so.

Petr^2 Spacek

> 
> displays the group, but "ipa group-find X" doesn't
> 
> How can get rid of the group so I can recreate the user ?
> 
> Many thanks
> 
> Bob

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Notification System

[Petr Spacek]

On 2.8.2016 16:13, Sébastien Julliot wrote:
> Hy everyone,
> 
> Currently migrating to FreeIPA, I find myself writing several scripts to
> notify users (on account creation, on birthdays, one week before account
> deletion, ...).
> 
> A global notification system would be very handy and I see here
>  that it has been on
> the tasklist for months now.
> 
> Do you have news about the progress and maybe a release date (estimated,
> at least) ?

Hello,

the student working on the project had given up for personal reasons so the
work is waiting for someone to pick it up.

I've updated ticket
https://fedorahosted.org/freeipa/ticket/1593#comment:17
including links to the work which was already been done.

> Besides, if necessary, we would be happy to synchronize and contribute
> to that part.

It would be awesome if you could look at the analysis which was done
(described in the documents linked from the ticket), read the design page and
return back to the mailing list with your proposal for implementation.

We were thinking about calling D-Bus from inside of FreeIPA framework which
would allow the user to hook up one or more custom scripts to the interesting
places in FreeIPA.

An alternative was a daemon which would watch LDAP tree using SyncRepl.

There is certainly some other way to deal with this, with own pros and cons.
Please propose your ;-)

Have a nice day!

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] slow login with freeipa 4.2.0

[Petr Spacek]

On 1.8.2016 09:08, Jakub Hrozek wrote:
> On Sat, Jul 30, 2016 at 02:02:56PM +0530, Rakesh Rajasekharan wrote:
>> Thanks Jakub for the detailed analysis... with those inputs , I was able to
>> nail down the issue.
>>
>> I had migrated this host from openldap to freeipa.. However, nslcd daemon
>> was still running and the sylog pointed me to the error "unable to contact
>> the earlier openldap server" and it spent some time there...
>>
>> So, I stopped nslcd and now logins have improved drastically to around 5s
>>
>> date;ssh testuser@localhost
>> Sat Jul 30 08:09:13 UTC 2016
>> testuser@localhost's password:
>> Last login: Sat Jul 30 08:08:55 2016 from 127.0.0.1
>> [p-rakeshpillai@prod1-admintools-1c :~] date
>> Sat Jul 30 08:09:18 UTC 2016
>>
>>
>> For the ipa_hostname entry in sssd.conf, that gets auto populated entered
>> everytime I run ipa-client-install .
>>
>> I run the below command to setup ipa client
>>
>> ipa-client-install --domain=xyz.xom --server=ipa-master-int.xyz.xom
>> --realm=xyz.xom -p admin --password=mypass--mkhomedir --hostname=10.65.16.4
>> --no-ssh --no-sshd -N -f -U

Hostname == IP address will break Kerberos authentication in cases where
client wants to connect using DNS name instead of IP address.

E.g. it will break "ssh user@server" where server is the machine you installed
using the command above.

Petr^2 Spacek

>>
>> Notice that, In the hostname argument, I am passing the IP address. Hope
>> thats fine, its actually working fine on around 2000+ servers in my
>> environment.
> 
> I wonder if this works only by accident. Even if you run
> ipa-client-install --hostname then you'll see in the help this is
> supposed to be FQDN. Kerberos got less picky about hostnames in the
> recent releases, but still..
> 
>>
>> I had earlier tried with servername.domain ( qa-test1.yyz.com as the
>> hostname ) and my servers hostname would get changed to  qa-test1.yyz.com .
>> However, we do our deployments on glassfish and glassfish somehow started
>> having issue everytime we restart glassfish ( not an expert with glassfish
>> ) so not sure whats wrong there.
>>
>> With this approach , my hostname is now my ipaddress and  things are
>> working fine both at galssfish and IPA side.
>> But just want to confirm its ok to do that
>>
>>
>> Thanks,
>> Rakesh
>>
>>
>>
>>
>>
>>
>> On Fri, Jul 29, 2016 at 5:10 PM, Jakub Hrozek  wrote:
>>
>>> On Tue, Jul 26, 2016 at 06:07:10PM +0530, Rakesh Rajasekharan wrote:
> Any change that it's running on a VM? If so, check your entropy:

> cat /proc/sys/kernel/random/entropy_avail

> If it's low (like < 1k), install haveged.

 this indeed is vm , am running it on azure . However, I have a similar
>>> set
 up running on aws which works completely fine
>>>
>>> Sorry about the delay in replying..
>>>

 The entropy was low, around 180, I installed haveged and now its above 3k
 cat /proc/sys/kernel/random/entropy_avail
 3178

 The timing though is still the same around 19s
>>>
>>> I have some comments inline about the config and logs.
>>>

 @jakub, i am reattaching the logs.

 The dns resoltion seems fast when I check using dig

 below is my sssd.conf
 [domain/xyz.com]
 selinux_provider=none
 krb5_auth_timeout = 20
 cache_credentials = True
 krb5_store_password_if_offline = True
 ipa_domain = xyz.com
 id_provider = ipa
 auth_provider = ipa
 access_provider = ipa
 ldap_tls_cacert = /etc/ipa/ca.crt
 ipa_hostname = 10.65.16.4
>>>
>>> The ipa_hostname value is wrong. It's meant for systems where hostname
>>> reports a different name that what is the name the host is registered as
>>> in IPA. Including an IP address there doesn't make much sense.
>>>
 chpass_provider = ipa
 ipa_server = ipa-master-in.xyz.com
 dns_discovery_domain = xyz.com
 ignore_group_members=True
 ldap_purge_cache_timeout = 0
 debug_level=8
 [sssd]
 services = nss, sudo, pam, ssh
 config_file_version = 2

 domains = xyz.com
 [nss]
 homedir_substring = /home

 [pam]
 pam_id_timeout = 3

 [sudo]

 [autofs]

 [ssh]

 [pac]

 [ifp]



 And here is the login times and logs

 [root@ipa-client-1 :~] date;ssh testuser@localhost
 Tue Jul 26 12:06:37 UTC 2016
 testuser@localhost's password:
 Last login: Tue Jul 26 12:03:53 2016 from 127.0.0.1
 [testuser@ipa-client-1 :~] date
 Tue Jul 26 12:06:55 UTC 2016


 sssd_domain logs

 (Tue Jul 26 12:06:40 2016) [sssd[be[xyz.com]]] [sbus_message_handler]
 (0x2000): Received SBUS method
 org.freedesktop.sssd.dataprovider.getAccountInfo on path
 /org/freedesktop/sssd/dataprovider
 (Tue Jul 26 12:06:40 2016) [sssd[be[xyz.com]]] [sbus_get_sender_id_send]
 (0x2000): Not a sysbus message, quit
 (Tue Jul 26 12:06:40 2016) [sssd[be[xyz.com]]] 

Re: [Freeipa-users] ipa-client install failurres, Could not resolve host: ipa-master-in.xyz.com; Unknown error

[Petr Spacek]

On 27.7.2016 19:29, Rakesh Rajasekharan wrote:
> Hi,
> 
> I am running ipa server 4.2 and set it up without using "--setup-dns=no".
> 
> On few clients the installation fails with the below error message.
> 
> 
> I verified that the ipa master dns is resolvable. Not sure what could be
> wrong here..
> 
> 
> Joining realm failed: libcurl failed to execute the HTTP POST transaction,
> explaining:  Could not resolve host: ipa-master-in.xyz.com; Unknown error
> 
> Use ipa-getkeytab to obtain a host principal for this server.
> Please make sure the following ports are opened in the firewall settings:
>  TCP: 80, 88, 389
>  UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
> Also note that following ports are necessary for ipa-client working
> properly after enrollment:
>  TCP: 464
>  UDP: 464, 123 (if NTP enabled)
> Failed to obtain host TGT: (-1765328203, 'Key table entry not found')
> Installation failed. Force set so not rolling back changes.
> 
> 
> I tried removeing /etc/ipa/ca.crt and delete any older certificates
> "certutil -D -n 'IPA CA' -d /etc/pki/nssdb"
> 
> However, no luck yet..
> 
> any suggestions on how can I debug this..

I would start with command:
$ dig ipa-master-in.xyz.com

It should print IPv4 address of the server ipa-master-in.xyz.com . If it does
not print it there is a problem with DNS. In that case usual DNS debugging
guides apply.

I hope it helps.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Replicating users/groups from AD

[Petr Spacek]

On 25.7.2016 15:30, Simo Sorce wrote:
> On Mon, 2016-07-25 at 08:24 -0500, Alston, David wrote:
>> Greetings!
>>
>>  Yes, I had been hoping there would be a way to incorporate domain
>> trusts between Active Directory and FreeIPA while the clients relying
>> on these for identity management shared the same DNS domain (eg.
>> linux.company.com and windows.company.com).  It sounds like that isn't
>> going to happen.
> 
> These are two different domains, as long as linuc.company.com is used
> only by freeIPA this configuration is already supported via trust
> relationship.

Let me add that there are workarounds for other cases as well:
http://rhelblog.redhat.com/2016/07/13/i-really-cant-rename-my-hosts/

Petr^2 Spacek


> 
>>  Account replication seems like another way for Active Directory
>> users to be able to login to servers to use the same username/password
>> for logging in.  It wouldn't have SSO, but at least a user would be
>> able to use the same username/password everywhere.  Replicating user
>> accounts from an external AD/LDAP server seems to be built-in, at the
>> moment.  There aren't any plans to take that away, is there?  Ideally,
>> I'd want a two way sync so that password changes and user group
>> changes are replicated back to AD as well.
> 
> winsync is not being further developed but we have no plans to take it
> away.
> 
> Simo.
> 
>> --David Alston
>>
>> -Original Message-
>> From: Simo Sorce [mailto:s...@redhat.com] 
>> Sent: Friday, July 22, 2016 10:49 AM
>> To: Alston, David
>> Cc: freeipa-users@redhat.com
>> Subject: Re: [Freeipa-users] Replicating users/groups from AD
>>
>> On Fri, 2016-07-22 at 09:59 -0500, Alston, David wrote:
>>> Greetings!
>>
>>>
>>
>>>  I realize that FreeIPA is supposed to be setup as master of its 
>>
>>> own domain, but are there any plans to continue the account 
>>
>>> replication functionality that has already been in FreeIPA?  I had 
>>
>>> heard rumor that it would be possible to have FreeIPA and Active 
>>
>>> Directory coexist in the same domain in some release in the future.
>>
>>> Am I waiting for a feature that will never come?
>>
>>
>> Hi David,
>> in order to respond to your question an idea of what are your expectations 
>> would is needed.
>>
>> If by Domain you mean "AD Domain or Kerberos Realm", the answer is no, they 
>> will never coexists.
>>
>> If by Domain you mean DNS Domain read then FreeIPA can work in the same 
>> domain as AD but only if you do not care for them interacting (at the 
>> kerberos level, no trusts, no SSO).
>> You can basically have only one association between a DNS domain and a 
>> Realm, and a DNS domain is either going to be associated to the AD Domain 
>> server or to the IPA Domain.
>>
>> Synchronization, however is a completely unrelated topic, and I can't give 
>> you an answer on that side as I do not understand how it would
>> relate to the coexistence of FreeIPA and AD in a single DNS domain.   
>>
>> Simo.
>>
>> --
>> Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Question DNS: DNS views & FreeIPA

[Petr Spacek]

On 22.7.2016 18:50, Günther J. Niederwimmer wrote:
> Hello List,
> 
> what is the best way to include a local DNS Server?

Could you be more specific? What exactly are you trying to achieve?

> Can I configure on a IPA DNS Server (extern) views for a internal  DNS 
> without 
> problems ?
> 
> Is the named Configuration is overwritten by Updates or other ?

Yes, the named.conf can be overwritten from time to time. FreeIPA-integrated
DNS "owns" that file and does modifications to it.

> I have read now much FreeIPA Doc's but found nothing for this Problem ?

The most important chapter is
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-determine-dns

"""
An IdM server with integrated DNS services
The integrated DNS server provided by IdM is not designed to be used as a
general-purpose DNS server. It only supports features related to IdM
deployment and maintenance. It does not support some of the advanced DNS
features.
"""

DNS views are out of scope of FreeIPA DNS. If you insist on using views you
will be on your own.


We plan to focus on integration with external DNS in some future release but
this work is not scoped yet. It would be great if you could provide us details
for your use-case so we can consider it in planning.

Thank you!

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA and slave MIT slave KDCs

[Petr Spacek]

On 21.7.2016 22:05, Diogenes S. Jesus wrote:
> Hi everyone.
> 
> I'm currently planning on deploying FreeIPA as the Master KDC (among other
> things to leverage from the API and some other built-in features - like
> replicas).
> However I find (correct if I'm wrong) FreeIPA not very modular - therefore
> I would like to know what's the strategy when deploying slave KDCs.
> 
> I've seen this thread
> 
> but I
> don't really want to have a replica - the idea was to deploy a separate box
> only running KDC - since the authentication is delegated to RADIUS for
> Authentication, I don't need to expose LDAP Master to KDC slaves - If yes,
> I would provide a read-only LDAP replica..
> 
> 
> For starters, where is the FreeIPA KDC stash file stored?

AFAIK there is no prior art in setting up MIT KDC slaves. First of all,
FreeIPA does not use stash file and stores master key in LDAP instead.

You can retrieve equivalent of stash file using following command:

$ ipa-getkeytab --retrieve --principal K/M@ -k /tmp/stash.keytab
--binddn='cn=Directory manager' --bindpw=''

*Make sure* that --retrieve option is present otherwise it will destroy your
Kerberos database.

The rest is up to your experimentation. I wish you good luck and please report
your findings back to the mailing list!

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] named-pkcs11 doesn't start after bind update

[Petr Spacek]

On 22.7.2016 04:43, Ben Lipton wrote:
> I'm not familiar enough with Fedora release engineering to know how this gets
> fixed permanently, but I'll share some investigation I've done.
> 
> This appears to be due to a change in the selinux-policy-targeted package that
> happened recently. As of the latest version, named-pkcs11 tries to run as type
> named_t instead of unconfined_service_t, but it isn't allowed to read the
> files from IPA [1]. When I downgraded to the selinux-policy and
> selinux-policy-targeted packages from [2] I was able to start named-pkcs11, so
> that might be a workaround you can use for now. Ultimately, the patch that
> fixes [3] might need to be backported to F23.

This is being tracked as
https://bugzilla.redhat.com/show_bug.cgi?id=1357665

Stay tuned.

Petr^2 Spacek

> 
> Ben
> 
> [1]
> 
> time->Fri Jul 22 04:17:44 2016
> type=AVC msg=audit(1469153864.756:705): avc:  denied  { read } for pid=11616
> comm="named-pkcs11" name="tokens" dev="dm-0" ino=26318195
> scontext=system_u:system_r:named_t:s0
> tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=dir permissive=1
> 
> time->Fri Jul 22 04:17:44 2016
> type=AVC msg=audit(1469153864.756:706): avc:  denied  { getattr } for 
> pid=11616 comm="named-pkcs11"
> path="/var/lib/ipa/dnssec/tokens/12cfb199-b2fe-d328-0b3a-e644756b73d6/token.object"
> dev="dm-0" ino=609982 scontext=system_u:system_r:named_t:s0
> tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=file permissive=1
> 
> time->Fri Jul 22 04:17:44 2016
> type=AVC msg=audit(1469153864.756:707): avc:  denied  { read write } for 
> pid=11616 comm="named-pkcs11" name="generation" dev="dm-0" ino=731584
> scontext=system_u:system_r:named_t:s0
> tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=file permissive=1
> 
> time->Fri Jul 22 04:17:44 2016
> type=AVC msg=audit(1469153864.757:708): avc:  denied  { open } for pid=11616
> comm="named-pkcs11"
> path="/var/lib/ipa/dnssec/tokens/12cfb199-b2fe-d328-0b3a-e644756b73d6/generation"
> dev="dm-0" ino=731584 scontext=system_u:system_r:named_t:s0
> tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=file permissive=1
> 
> time->Fri Jul 22 04:17:44 2016
> type=AVC msg=audit(1469153864.757:709): avc:  denied  { lock } for pid=11616
> comm="named-pkcs11"
> path="/var/lib/ipa/dnssec/tokens/12cfb199-b2fe-d328-0b3a-e644756b73d6/generation"
> dev="dm-0" ino=731584 scontext=system_u:system_r:named_t:s0
> tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=file permissive=1
> 
> [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=758088
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1333106
> 
> On 07/21/2016 05:51 PM, Roberto Cornacchia wrote:
>> UPDATE:
>>
>> Tried again the whole procedure with ipa-dns-install, and it DOES work with
>> SElinux disable, and still fails with SElinux enabled.
>>
>> So the error "Failed to enumerate object store in /var/lib/softhsm/tokens/"
>> makes sense.
>>
>> Can someone help me fix it?
>>
>> $ ll -Z /var/lib/ipa/dnssec/
>> total 12
>> -rwxrwx---. 1 ods named unconfined_u:object_r:ipa_var_lib_t:s0   30 Jul 21
>> 22:50 softhsm_pin*
>> drwxrws---. 3 ods named unconfined_u:object_r:ipa_var_lib_t:s0 4096 Jul 21
>> 22:50 tokens/
>>
>>
>>
>> On 21 July 2016 at 23:11, Roberto Cornacchia > > wrote:
>>
>> - FC23
>> - IPA 4.2.4
>>
>> After a dnf update, bind was updated (no ipa updates),
>> and named-pkcs11 doesn't start anymore.
>>
>>
>> $ /usr/sbin/named-pkcs11 -d 9 -g
>> 21-Jul-2016 23:08:50.332 starting BIND
>> 9.10.3-P4-RedHat-9.10.3-13.P4.fc23  -d 9 -g
>> 21-Jul-2016 23:08:50.332 built with
>> '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu'
>> '--program-prefix=' '--disable-dependency-tracking'
>> '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin'
>> '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share'
>> '--includedir=/usr/include' '--libdir=/usr/lib64'
>> '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib'
>> '--mandir=/usr/share/man' '--infodir=/usr/share/info'
>> '--with-python=/usr/bin/python3' '--with-libtool'
>> '--localstatedir=/var' '--enable-threads' '--enable-ipv6'
>> '--enable-filter-' '--with-pic' '--disable-static'
>> '--disable-openssl-version-check'
>> '--includedir=/usr/include/bind9' '--with-tuning=large'
>> '--with-geoip' '--enable-native-pkcs11'
>> '--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so'
>> '--with-dlopen=yes' '--with-dlz-ldap=yes'
>> '--with-dlz-postgres=yes' '--with-dlz-mysql=yes'
>> '--with-dlz-filesystem=yes' '--with-dlz-bdb=yes'
>> '--with-gssapi=yes' '--disable-isc-spnego' '--enable-fixed-rrset'
>> '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets'
>> '--enable-full-report' 'build_alias=x86_64-redhat-linux-gnu'
>> 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall
>> 

Re: [Freeipa-users] non-authoritative tricks for DNS resolution

[Petr Spacek]

On 18.7.2016 23:06, Brendan Kearney wrote:
> On 07/18/2016 06:12 AM, Petr Spacek wrote:
>> On 18.7.2016 03:25, Sullivan, Daniel [AAA] wrote:
>>> Would a DNS view (bind) work?
>>>
>>> http://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_06.htm
>>>
>>> Also, depending on what you are using for NAT, some devices will mangle the
>>> reply payload of A record lookups as they traverse NAT to avoid haripinning
>>> (a packet going out and then back in the same interface as it traverses
>>> NAT).  This is known as DNS doctoring, at least in the world of Cisco.
>>>
>>> http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/72273-dns-doctoring-3zones.html
>>>
>>>
>>> Let me know if either of those will solve your problem.  If not, I might
>>> have a misunderstanding of what you are asking.
>>>
>>> Dan
>>>
>>>> On Jul 17, 2016, at 3:36 PM, Brendan Kearney <bpk...@gmail.com> wrote:
>>>>
>>>> i am looking to setup a VPN in order to access some resources, and want to
>>>> point my clients at this resource via DNS.  the resource i am accessing is
>>>> internet resolvable, but i am accessing it via the VPN, and using a NAT
>>>> for the VPN (full 1-to-1 or static NAT).  i want to have a record in my
>>>> DNS for this resource, using its proper name (which i am not authoritative
>>>> for), but assign it the IP of my NAT.
>>>>
>>>> say for example, host.domain-ext.tld is the resource i want to access, and
>>>> it resolves externally to 1.2.3.4.  my VPN NAT would be 192.168.99.137.  i
>>>> want internal resolution of DNS to point to 192.168.99.137 so the network
>>>> routing takes my internal clients to the VPN and not out to the internet.
>>>>
>>>> i am using isc bind, bind-dyndb-ldap, and fedora, but not freeipa, for
>>>> dns.  how do i setup the zone and record to accomplish this DNS trick?  i
>>>> have talked with some DNS gurus and they indicate that i can do something
>>>> with the "@" record.  it seems that the record i want, would be its own
>>>> zone, and the @ record would point to the name, and the SOA would be the
>>>> NAT IP.  i could be wrong about the details, but something like this is
>>>> how to setup resolution the way i want.
>>>>
>>>> any pointers would be greatly appreciated.
>> Background note:
>> All these DNS tricks are hacks to work around IP routing problem in
>> configuration you described.
>>
>> If you really want to use DNS tricks, you can create a DNS zone with name
>> equal to the you want to override and will this zone with A/ record at
>> zone apex (@).
>> The DNS approach has some inherent advantages:
>>
>> 1. All DNS names below the name you want to 'hijack' will not be resolvable 
>> in
>> your network. E.g. if the name is hijacked.example.com. then sub-domains like
>> anything.hijacked.example.com. will not be resolvable.
>>
>> 2. Your clients will go securely over VPN if and only if they use your local
>> DNS servers. Any client configured (even accidentally) to use some other DNS
>> server (e.g. public 8.8.8.8) will get the 'public' address and do not tunnel
>> the traffic over VPN.
>>
>>
>> Secure and reliable solution is not to use DNS but solve things on IP layer:
>> On the network gateway, configure IPSec tunnel (or any other VPN) in a way
>> that *the original IP address* is routed over VPN.
>>
>> This does not require any DNS tricks and thus will work regardless of client
>> configuration.
>>
>> I hope it helps.
>>
> our posture states that we do not route network space that is not ours, unless
> exigent circumstances dictate otherwise.  we have dedicated address space to
> NAT pools, in order to facilitate this. we also forbid external dns resolution
> from endpoints, by limiting what can go out to the roots for recursion. 

Blocking port 53 is slowly becoming a pointless exercise as RFC 7858 gets
incrementally adopted. DNS is going to be indistinguishable from any TLS
traffic, potentially even over port 443.

Having said that, it is better to plan for changes sooner than later.


> misconfigured clients are not able to perform DNS resolution.  we work with
> our counterparts on the other side of the VPN to ensure we are only adding a
> host record, and that sub-domains are not a point of failure for our access.
> 
> in terms of setting up this zone, how would one construct the ldi

Re: [Freeipa-users] non-authoritative tricks for DNS resolution

[Petr Spacek]

On 18.7.2016 03:25, Sullivan, Daniel [AAA] wrote:
> Would a DNS view (bind) work?
> 
> http://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_06.htm
> 
> Also, depending on what you are using for NAT, some devices will mangle the 
> reply payload of A record lookups as they traverse NAT to avoid haripinning 
> (a packet going out and then back in the same interface as it traverses NAT). 
>  This is known as DNS doctoring, at least in the world of Cisco.
> 
> http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/72273-dns-doctoring-3zones.html
> 
> Let me know if either of those will solve your problem.  If not, I might have 
> a misunderstanding of what you are asking.
> 
> Dan
> 
>> On Jul 17, 2016, at 3:36 PM, Brendan Kearney  wrote:
>>
>> i am looking to setup a VPN in order to access some resources, and want to 
>> point my clients at this resource via DNS.  the resource i am accessing is 
>> internet resolvable, but i am accessing it via the VPN, and using a NAT for 
>> the VPN (full 1-to-1 or static NAT).  i want to have a record in my DNS for 
>> this resource, using its proper name (which i am not authoritative for), but 
>> assign it the IP of my NAT.
>>
>> say for example, host.domain-ext.tld is the resource i want to access, and 
>> it resolves externally to 1.2.3.4.  my VPN NAT would be 192.168.99.137.  i 
>> want internal resolution of DNS to point to 192.168.99.137 so the network 
>> routing takes my internal clients to the VPN and not out to the internet.
>>
>> i am using isc bind, bind-dyndb-ldap, and fedora, but not freeipa, for dns.  
>> how do i setup the zone and record to accomplish this DNS trick?  i have 
>> talked with some DNS gurus and they indicate that i can do something with 
>> the "@" record.  it seems that the record i want, would be its own zone, and 
>> the @ record would point to the name, and the SOA would be the NAT IP.  i 
>> could be wrong about the details, but something like this is how to setup 
>> resolution the way i want.
>>
>> any pointers would be greatly appreciated.

Background note:
All these DNS tricks are hacks to work around IP routing problem in
configuration you described.

If you really want to use DNS tricks, you can create a DNS zone with name
equal to the you want to override and will this zone with A/ record at
zone apex (@).
The DNS approach has some inherent advantages:

1. All DNS names below the name you want to 'hijack' will not be resolvable in
your network. E.g. if the name is hijacked.example.com. then sub-domains like
anything.hijacked.example.com. will not be resolvable.

2. Your clients will go securely over VPN if and only if they use your local
DNS servers. Any client configured (even accidentally) to use some other DNS
server (e.g. public 8.8.8.8) will get the 'public' address and do not tunnel
the traffic over VPN.


Secure and reliable solution is not to use DNS but solve things on IP layer:
On the network gateway, configure IPSec tunnel (or any other VPN) in a way
that *the original IP address* is routed over VPN.

This does not require any DNS tricks and thus will work regardless of client
configuration.

I hope it helps.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Can I migrate group password hashes from NIS?

[Petr Spacek]

On 12.7.2016 17:13, Joanna Delaporte wrote:
> Hi Rob,
> 
> I'm sorry, I don't know how to list available pre-defined attributes, and I
> wasn't able to find it just now looking through the help menu. Is the
> attribute key grpassword, grouppassword, or something else?

The attribute called 'userpassword' can be added to 'posixGroup' object class
as well. I would start with that, but again, it is completely untested.

Please report your finding, I'm curious :-)

Petr^2 Spacek

> On Wed, Jul 6, 2016 at 4:24 PM, Rob Crittenden  wrote:
> 
>> Joanna Delaporte wrote:
>>
>>> I have successfully migrated some user password hashes from an NIS
>>> domain. I am wondering if there is a similar method for migrating group
>>> passwords. I haven't found any discussion or documentation on it.
>>>
>>
>> You do it the same way as users. Note that there are no IPA commands to
>> manage a group password and group passwords are completely untested (the
>> attribute is available though).

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] DNS service named in one of our IPA server cannot start

[Petr Spacek]

On 9.7.2016 02:47, lm gnid wrote:
> Hello,
> 
> In one of our IPA server, named service suddenly cannot start, so I followed  
> the link bellow:
> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart
> 
> Found some errors like bellow:
> 
> ==> messages <==
> 
> Jul  8 23:30:30 eupreprd-ops-ipa-01 named-pkcs11[5002]: LDAP error: Invalid 
> credentials: SASL(-14): authorization failure: : bind to LDAP server failed
> 
> It should be a "Invalid credentials: bind to LDAP server failed " error, 
> however, the commands bellow shows no issues to me:
> 
> [root@eupreprd-ops-ipa-01 ~]# kvno 
> DNS/eupreprd-ops-ipa-01.internal@internal.com
> 
> DNS/eupreprd-ops-ipa-01.internal@internal.com: kvno = 2
> 
> [root@eupreprd-ops-ipa-01 ~]# klist -kt /etc/named.keytab
> 
> Keytab name: FILE:/etc/named.keytab
> 
> KVNO Timestamp   Principal
> 
>  --- 
> --
> 
>2 06/10/2016 17:57:38 DNS/eupreprd-ops-ipa-01.internal@internal.com
> 
>2 06/10/2016 17:57:38 DNS/eupreprd-ops-ipa-01.internal@internal.com
> 
>2 06/10/2016 17:57:38 DNS/eupreprd-ops-ipa-01.internal@internal.com
> 
>2 06/10/2016 17:57:38 DNS/eupreprd-ops-ipa-01.internal@internal.com
> 
>2 06/10/2016 17:57:38 DNS/eupreprd-ops-ipa-01.internal@internal.com
> 
>2 06/10/2016 17:57:38 DNS/eupreprd-ops-ipa-01.internal@internal.com
> 
> 
> 
> [root@eupreprd-ops-ipa-01 ~]# kinit -kt /etc/named.keytab 
> DNS/eupreprd-ops-ipa-01.internal.com
> 
> [root@eupreprd-ops-ipa-01 ~]
> 
> 
> 
> [root@eupreprd-ops-ipa-01 ~]# ldapsearch -H 
> 'ldapi://%2fvar%2frun%2fslapd-INTERNAL-COM.socket"' -Y GSSAPI -b 'cn=dns, 
> dc=internal,dc=com'
> 
> ..
> 
> 
> 
> For now, I have use the "(Workaround) Use simple LDAP BIND insted of 
> Kerberos" to make it work, but still want to know how to recover to "sasl"?


Huh, this is really weird. The only idea I have is that there is some
replication issue between the IPA servers so server1 has different key for the
DNS service principal than server2.

In theory servers to contact can be chosen randomly (in theory) so named might
have been unlucky and attempted to contact 'wrong' server while kinit might
have been lucky and contacted the 'right' one.

Please check things mentioned in
http://www.freeipa.org/page/Troubleshooting#Replication_issues

I hope it helps!

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] steps to debug SOA serial being out of sync?

[Petr Spacek]

On 11.7.2016 15:40, Anthony Clark wrote:
> Thanks for the answer,
> 
> I just wanted to confirm:  Various "DNS health checks" complain about SOA
> serials not being the same.  Are those safe to ignore?

Yes, unless you are doing incremental zone transfers.

> I have 2 FreeIPA servers for basic redundancy.  Should I not be pointing my
> hosts at both FreeIPA hosts for DNS?

It is okay to point clients to both servers as long as the clients are not
doing incremental zone transfers.

If you plan to do incremental zone transfers, point client to single IPA
servers. That is it.

Petr^2 Spacek

> Anthony
> 
> On Mon, Jul 11, 2016 at 3:33 AM, Petr Spacek <pspa...@redhat.com> wrote:
> 
>> On 8.7.2016 19:13, Anthony Clark wrote:
>>> Hello All,
>>>
>>> I have two FreeIPA servers set up as follows:
>>>
>>> ns01:  ipa-server-install --realm=DEV.REDACTED.NET --mkhomedir
>> --setup-dns
>>> --ssh-trust-dns --forwarder=1.2.3.4
>>>
>>> ns02:  ipa-replica-install
>>> /var/lib/ipa/replica-info-ns02.dev.redacted.net.gpg --setup-ca
>> --mkhomedir
>>> --ssh-trust-dns --setup-dns --forwarder=1.2.3.4
>>>
>>>
>>> Now, after being in use for a few months, my SOA serial numbers are
>>> different as reported by the two servers:
>>>
>>> ns01 reports 1467996578
>>> ns02 reports 1467996455
>>>
>>> [root@ns02 ~]# ipa dnszone-show dev.redacted.net
>>> ...
>>>   SOA serial: 1467996455
>>> ...
>>>
>>> Same result on ns01, 1467996455
>>>
>>> ipa-replica-conncheck is fine.
>>>
>>> After an "ipactl restart" on ns02 (thinking that I needed to refresh the
>>> ns02 FreeIPA instance somehow) the SOA serial on ns02 increments *beyond*
>>> that of ns01:
>>>
>>> ns01: 1467996578
>>> ns02:  1467997519
>>>
>>> Another "ipactl restart" on ns02 results in:
>>>
>>> ns01:  1467996578
>>> ns02:  1467997595
>>>
>>> running "ipactl restart" on ns01 results in:
>>>
>>> ns01:  1467997873
>>> ns02:  1467997595
>>>
>>> ns02 doesn't seem to be getting its serial number from ns01 at all.
>>>
>>> Did I set up ns02 incorrectly?  Should I have skipped the "--setup-dns"
>> on
>>> the replica?
>>>
>>> Does anyone have any suggestions on how to debug this further?
>>
>> Hello,
>>
>> this is in fact expected. IPA has multi-master DNS so serials are not
>> synced.
>>
>> This is documented in
>>
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#zone-transfers
>>
>> I hope it helps.
>>
>> --
>> Petr^2 Spacek
>>
> 


-- 
Petr Spacek  @  Red Hat

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] steps to debug SOA serial being out of sync?

[Petr Spacek]

On 8.7.2016 19:13, Anthony Clark wrote:
> Hello All,
> 
> I have two FreeIPA servers set up as follows:
> 
> ns01:  ipa-server-install --realm=DEV.REDACTED.NET --mkhomedir --setup-dns
> --ssh-trust-dns --forwarder=1.2.3.4
> 
> ns02:  ipa-replica-install
> /var/lib/ipa/replica-info-ns02.dev.redacted.net.gpg --setup-ca --mkhomedir
> --ssh-trust-dns --setup-dns --forwarder=1.2.3.4
> 
> 
> Now, after being in use for a few months, my SOA serial numbers are
> different as reported by the two servers:
> 
> ns01 reports 1467996578
> ns02 reports 1467996455
> 
> [root@ns02 ~]# ipa dnszone-show dev.redacted.net
> ...
>   SOA serial: 1467996455
> ...
> 
> Same result on ns01, 1467996455
> 
> ipa-replica-conncheck is fine.
> 
> After an "ipactl restart" on ns02 (thinking that I needed to refresh the
> ns02 FreeIPA instance somehow) the SOA serial on ns02 increments *beyond*
> that of ns01:
> 
> ns01: 1467996578
> ns02:  1467997519
> 
> Another "ipactl restart" on ns02 results in:
> 
> ns01:  1467996578
> ns02:  1467997595
> 
> running "ipactl restart" on ns01 results in:
> 
> ns01:  1467997873
> ns02:  1467997595
> 
> ns02 doesn't seem to be getting its serial number from ns01 at all.
> 
> Did I set up ns02 incorrectly?  Should I have skipped the "--setup-dns" on
> the replica?
> 
> Does anyone have any suggestions on how to debug this further?

Hello,

this is in fact expected. IPA has multi-master DNS so serials are not synced.

This is documented in
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#zone-transfers

I hope it helps.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Error with DNS forwarding on replica.

[Petr Spacek]

On 15.6.2016 09:37, Nuno Higgs wrote:
> Hello Petr,
> 
> [root@slave ~]# cat  /var/log/ipareplica-install.log | grep -i DNSSEC | grep 
> -i not | grep -i support
> 
> It’s empty.

Interesting. At this point I'm unable to say what happened to your install. If
it happens again please get back to us and we will investigate.

Petr^2 Spacek

> 
> Thanks
> Nuno
> 
>> On 15 Jun 2016, at 07:45, Petr Spacek <pspa...@redhat.com> wrote:
>>
>> On 14.6.2016 17:29, Nuno Higgs wrote:
>>> Hello,
>>>
>>> I am running CentOS7:
>>>
>>> ipa-server-4.2.0-15.0.1.el7.centos.6.1.x86_64
>>>
>>> I configured my dos forward when i did the install process of the secondary 
>>> node of IPA:
>>>
>>> [root@slave ~]#  ipa-replica-install --setup-ca --setup-dns --forwarder  
>>> 10.0.157.35 /var/lib/ipa/replica-info-slave.ipa.domain.local.gpg
>>
>> Interesting, 4.2.0 should checks to detect this problem.
>>
>> Could you check /var/log/ipareplica-install.log for warnings related to 
>> DNSSEC?
>>
>> It should be something like
>> "DNS server  does not support DNSSEC"
>>
>> Thanks.
>>
>> Petr^2 Spacek
>>
>>
>>>
>>> Thanks,
>>> Nuno
>>>
>>>> On 14 Jun 2016, at 15:28, Petr Spacek <pspa...@redhat.com> wrote:
>>>>
>>>> On 14.6.2016 13:01, Nuno Higgs wrote:
>>>>> Hello,
>>>>>
>>>>> Found it:
>>>>>
>>>>> It appears that my forwarder is NOT DNSSEC happy:
>>>>>
>>>>> in:  /var/named/data/named.run
>>>>>
>>>>> validating @0x7f2c40044910: . DNSKEY: got insecure response; parent 
>>>>> indicates it should be secure
>>>>> error (insecurity proof failed) resolving './DNSKEY/IN': 10.0.157.35#53
>>>>>
>>>>> So, i changed the /etc/named.conf 
>>>>>
>>>>> from:
>>>>>
>>>>>   dnssec-enable yes;
>>>>>   dnssec-validation yes;
>>>>>
>>>>> to:
>>>>>
>>>>>   dnssec-enable yes;
>>>>>   dnssec-validation no;
>>>>>
>>>>> Everything is working fine now.
>>>>
>>>> Okay, it explains a lot.
>>>>
>>>> Please note that configuration "dnssec-validation no;" lowers security bar 
>>>> for
>>>> attackers and is strongly discouraged!
>>>>
>>>> The issue is most likely caused by non-compliant forwarder which mangles 
>>>> DNS
>>>> data somehow before they reach your IPA DNS server.
>>>>
>>>> I would recommend you to check DNS forwarder on 10.0.157.35 and see it is
>>>> configured with its equivalent of "dnssec-enable yes;". I strongly 
>>>> recommend
>>>> returning back to "dnssec-validation yes;" after fixing the forwarder 
>>>> config.
>>>>
>>>> IPA 4.3 or newer should print a warning about such broken forwarders 
>>>> whenever
>>>> you try to configure them using IPA commands.
>>>>
>>>> What version of IPA do you use?
>>>>
>>>> How did you configure the forwarder in IPA?
>>>>
>>>> Petr^2 Spacek
>>>>
>>>>>
>>>>> Thanks for your help!
>>>>> Nuno
>>>>>
>>>>>> On 13 Jun 2016, at 10:14, Nuno Higgs <i...@border.nuneshiggs.com> wrote:
>>>>>>
>>>>>> Hello again,
>>>>>>
>>>>>> [root@ipa01 ~]# kinit user
>>>>>> Password for user@DOMAIN.LOCAL:
>>>>>> [root@ipa01 ~]# ipa dnsforwardzone-show domain.eu
>>>>>> Zone name: domain.eu.
>>>>>> Active zone: TRUE
>>>>>> Zone forwarders: 194.65.3.20 195.65.3.21
>>>>>> Forward policy: only
>>>>>> [root@ipa01 ~]#
>>>>>>
>>>>>>
>>>>>> [root@ipa02 ~]# ipa dnsforwardzone-show domain.eu
>>>>>> Zone name: domain.eu.
>>>>>> Active zone: TRUE
>>>>>> Zone forwarders: 194.65.3.20 195.65.3.21
>>>>>> Forward policy: only
>>>>>> [root@ipa02 ~]#
>>>>>>
>>>>>> On both servers the return is the same.
>>>>>> I haven't touched the DNS config besides deleting 

Re: [Freeipa-users] ipa-ods-exporter failed ?

[Petr Spacek]

On 7.7.2016 11:32, Günther J. Niederwimmer wrote:
> Hello Petr,
> 
> Am Donnerstag, 7. Juli 2016, 09:14:35 CEST schrieb Petr Spacek:
>> On 23.6.2016 15:27, Günther J. Niederwimmer wrote:
>>> Hello Martin,
>>>
>>> Am Donnerstag, 23. Juni 2016, 15:02:18 CEST schrieb Martin Basti:
>>>> On 20.06.2016 18:48, Günther J. Niederwimmer wrote:
>>>>> Hello,
>>>>>
>>>>> Am Montag, 20. Juni 2016, 09:54:11 CEST schrieb Petr Spacek:
>>>>>> On 18.6.2016 15:03, Günther J. Niederwimmer wrote:
>>>>>>> hello,
>>>>>>>
>>>>>>> Am Freitag, 17. Juni 2016, 23:05:32 CEST schrieb Martin Basti:
>>>>>>>> On 17.06.2016 18:29, Günther J. Niederwimmer wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Am Freitag, 17. Juni 2016, 14:13:55 CEST schrieb Martin Basti:
>>>>>>>>>> On 17.06.2016 12:54, Günther J. Niederwimmer wrote:
>>>>>>>>>>> Hello List,
>>>>>>>>>>>
>>>>>>>>>>> Am Freitag, 17. Juni 2016, 07:51:45 CEST schrieb Petr Spacek:
>>>>>>>>>>>> On 16.6.2016 21:51, Lukas Slebodnik wrote:
>>>>>>>>>>>>> On (16/06/16 11:54), Günther J. Niederwimmer wrote:
>>>>>>>>>>>>>> Hello
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> on my system the ods-exporter i mean have a problem.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have this in the logs
>>>>>>>>>>>>>> CentOS 7.(2) ipa 4.3.1
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jun 16 11:38:28 ipa ipa-ods-exporter: raise
>>>>>>>>>>>>>> errors.ACIError(info=info)
>>>>>>>>>>>>>> Jun 16 11:38:28 ipa ipa-ods-exporter: ipalib.errors.ACIError:
>>>>>>>>>>>>>> Insufficient
>>>>>>>>>>>>>> access: SASL(-1): generic failure: GSSAPI Error: Unspecified
>>>>>>>>>>>>>> GSS
>>>>>>>>>>>>>> failure.
>>>>>>>>>>>>>> Minor code may provide more information (Ticket expired)
>>>>>>>>>>>>>   
>>>>>>>>>>>>>   Here seems to be a reason why it failed.
>>>>>>>>>>>>>   But I can't help you more.
>>>>>>>>>>>>
>>>>>>>>>>>> Lukas is right. Interesting, this should never happen :-)
>>>>>>>>>>>
>>>>>>>>>>> this have I also found ;-)
>>>>>>>>>>>
>>>>>>>>>>>> Please enable debugging using procedure
>>>>>>>>>>>> http://www.freeipa.org/page/Troubleshooting#ipa_command_crashes_o
>>>>>>>>>>>> r_
>>>>>>>>>>>> re
>>>>>>>>>>>> tu
>>>>>>>>>>>> rn
>>>>>>>>>>>> s_n o_data and check logs after next ipa-ods-exporter restart.
>>>>>>>>>>>> Thank you!
>>>>>>>>>>>
>>>>>>>>>>> OK,
>>>>>>>>>>>
>>>>>>>>>>> I attache the messages log?
>>>>>>>>>>>
>>>>>>>>>>> I mean this is a problem with my DNS ?
>>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>> can you check kerberos status of ipa-ods-exporter service in webUI?
>>>>>>>>>>
>>>>>>>>>> identity/services/ipa-ods-exported/
>>>>>>>>>> There should be kerberos status in right top corner in details view
>>>>>>>>>
>>>>>>>>> I have a
>>>>>>>>> identity/services/ipa-ods-exporter/..
>>>>>>>>>
>>>>>>>>> with a "Kerberos Key Present, Service Pr

Re: [Freeipa-users] Sync & BaseDN change

[Petr Spacek]

On 7.7.2016 01:44, Brad Cesarone wrote:
> I have two questions
> 1) Is it possible to sync/replicate with another ldap server? i.e Oracle
> Identity Manager

IPA provides one-time import script called ipa-migrate-ds, see
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/using-migrate-ds.html

It does not have any run-time synchronization capabilities.

> 2) If #1 is true, is it possible to sync with two different suffixs?

No.

> 3) Is it possible to either install IPA with a custom ldap Suffix or change
> the suffix once it is created?

No, the suffix is derived from Kerberos realm and stays the same for lifetime
of the IPA installation.


What are you trying to achieve? Maybe we can approach it from a different angle.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-ods-exporter failed ?

[Petr Spacek]

On 23.6.2016 15:27, Günther J. Niederwimmer wrote:
> Hello Martin,
> 
> Am Donnerstag, 23. Juni 2016, 15:02:18 CEST schrieb Martin Basti:
>> On 20.06.2016 18:48, Günther J. Niederwimmer wrote:
>>> Hello,
>>>
>>> Am Montag, 20. Juni 2016, 09:54:11 CEST schrieb Petr Spacek:
>>>> On 18.6.2016 15:03, Günther J. Niederwimmer wrote:
>>>>> hello,
>>>>>
>>>>> Am Freitag, 17. Juni 2016, 23:05:32 CEST schrieb Martin Basti:
>>>>>> On 17.06.2016 18:29, Günther J. Niederwimmer wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Am Freitag, 17. Juni 2016, 14:13:55 CEST schrieb Martin Basti:
>>>>>>>> On 17.06.2016 12:54, Günther J. Niederwimmer wrote:
>>>>>>>>> Hello List,
>>>>>>>>>
>>>>>>>>> Am Freitag, 17. Juni 2016, 07:51:45 CEST schrieb Petr Spacek:
>>>>>>>>>> On 16.6.2016 21:51, Lukas Slebodnik wrote:
>>>>>>>>>>> On (16/06/16 11:54), Günther J. Niederwimmer wrote:
>>>>>>>>>>>> Hello
>>>>>>>>>>>>
>>>>>>>>>>>> on my system the ods-exporter i mean have a problem.
>>>>>>>>>>>>
>>>>>>>>>>>> I have this in the logs
>>>>>>>>>>>> CentOS 7.(2) ipa 4.3.1
>>>>>>>>>>>>
>>>>>>>>>>>> Jun 16 11:38:28 ipa ipa-ods-exporter: raise
>>>>>>>>>>>> errors.ACIError(info=info)
>>>>>>>>>>>> Jun 16 11:38:28 ipa ipa-ods-exporter: ipalib.errors.ACIError:
>>>>>>>>>>>> Insufficient
>>>>>>>>>>>> access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS
>>>>>>>>>>>> failure.
>>>>>>>>>>>> Minor code may provide more information (Ticket expired)
>>>>>>>>>>>>
>>>>>>>>>>>  ^^
>>>>>>>>>>>   
>>>>>>>>>>>   Here seems to be a reason why it failed.
>>>>>>>>>>>   But I can't help you more.
>>>>>>>>>>
>>>>>>>>>> Lukas is right. Interesting, this should never happen :-)
>>>>>>>>>
>>>>>>>>> this have I also found ;-)
>>>>>>>>>
>>>>>>>>>> Please enable debugging using procedure
>>>>>>>>>> http://www.freeipa.org/page/Troubleshooting#ipa_command_crashes_or_
>>>>>>>>>> re
>>>>>>>>>> tu
>>>>>>>>>> rn
>>>>>>>>>> s_n o_data and check logs after next ipa-ods-exporter restart.
>>>>>>>>>> Thank you!
>>>>>>>>>
>>>>>>>>> OK,
>>>>>>>>>
>>>>>>>>> I attache the messages log?
>>>>>>>>>
>>>>>>>>> I mean this is a problem with my DNS ?
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>> can you check kerberos status of ipa-ods-exporter service in webUI?
>>>>>>>>
>>>>>>>> identity/services/ipa-ods-exported/
>>>>>>>> There should be kerberos status in right top corner in details view
>>>>>>>
>>>>>>> I have a
>>>>>>> identity/services/ipa-ods-exporter/..
>>>>>>>
>>>>>>> with a "Kerberos Key Present, Service Provisioned"
>>>>>>>
>>>>>>> but no Certificate ?
>>>>>>
>>>>>> Can you try,
>>>>>>
>>>>>> # kinit -kt /etc/ipa/dnssec/ipa-ods-exporter.keytab
>>>>>> ipa-ods-exporter/$(hostname)
>>>>>
>>>>> OK
>>>>> I can do a "kinit -kt /etc/ipa/dnssec/ipa-ods-exporter.keytab ipa-ods-
>>>>> exporter/$(hostname)"
>>>>>
>>>>> written on one line!! is this OK.
>>>>>
>>>>>> and do ldapsea

Re: [Freeipa-users] dns zone forward - no valid signature found

[Petr Spacek]

On 6.7.2016 16:37, lejeczek wrote:
> hi everybody
> 
> I think this was working some time ago, but for while queries IPA's DNS
> forwards wound up like this:
> 
> validating @0x7f85dc00f9a0: swir.my.dom A: no valid signature found
> validating @0x7f85dc00f9a0: swir.my.dom A: bad cache hit (swir.my.dom/DS)
> error (broken trust chain) resolving 'swir.my.dom/A/IN': 192.168.2.100#53
> 
> dig at IPA DNS and nothing, logs:
> 
>   validating @0x7f85e0134880: my.dom SOA: no valid signature found
>   validating @0x7f85e0134880: my.dom NSEC: no valid signature found
>   validating @0x7f85e0134880: swir.my.dom NSEC: no valid signature found
>   validating @0x7f85e0134880: swir.my.dom NSEC: bad cache hit (swir.my.dom/DS)
> 
> I dig +dnssec directly at the receiving server and result seems normal, no
> errors.
> 
> IPA's dns is not dnsseced, is this the root of the problem? Or what else might
> be?

Obfuscated domain names are making impossible to tell where the problem lies.

Try dnsviz.net or similar tool, enter domain name into it and let it diagnose
the domain for you. If DNSviz claims that the domain is correctly signed (or
not) then the problem is likely in forwarder configuration.

All forwarders used in your DNS chain have to be configured with equivalent of
named.conf option 'dnssec-enable yes;'.

I hope this helps.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] +dnssec in vendor repos - when?

[Petr Spacek]

On 6.7.2016 10:35, lejeczek wrote:
> seems like official repos, centos at least lags a bit behind, currently it's
> 4.2.0 - question - does this support fully secure dns ?

Version 4.2.0 is not the best for DNSSEC deployment.

IPA 4.3.1 contains important fixes related to DNSSEC.

Please note that even 4.3.1 contains some bug which may force you to restart
named-pkcs11 from time to time. We did not find the root cause yet.

> if not would devel know when we might be able to feed new/latest stable off
> the official repos?

Exact date is unclear, as usual. Stay tuned :-)

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Kerberois FreeIPA Question

[Petr Spacek]

On 3.7.2016 14:19, Günther J. Niederwimmer wrote:
> Hello,
> 
> Is it possible to create a kerberos Ticket for a secondary domain ?
> 
> CentOS 7.2 IPA 4.3.1
> My installing,
> I have a IPAServer for
> 
> Domain
> test.com
> 
> LDAP & Kerberos
> TEST.COM
> 
> now i like to include a other Domain
> new.net
> 
> Is it possible to have for this domain also a kerberos ticket ?
> 
> I found a example in a krb5.conf like this
> [domain_realm]
> .test.com = TEST.COM
> .new.net = TEST.COM
> ...
> 
> is this possible with FreeIPA ?

One FreeIPA instance always represents one Kerberos REALM. At the same time
multiple DNS domains can belong to one FreeIPA REALM. See command 'ipa
realmdomains'.


-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Small bug in ipa-backup file naming

[Petr Spacek]

On 2.7.2016 22:00, Joshua J. Kugler wrote:
> Was just playing around with the ipa-backup scripts for a client. Ran ipa-
> backup, and the backup was successfully placed in /var/lib/ipa/backup/ipa-
> full-2016-07-02-11-54-58. Went to view ipa-full.tar, and discovered it's 
> actually a tar.gz file.  This is FreeIPA 4.2.0 on CentOS 7.
> 
> Is this known? Or should I open a bug?

Please open a ticket:
https://fedorahosted.org/freeipa/newticket

Thank you!

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] how to make fIPA stick to only...

[Petr Spacek]

On 1.7.2016 16:29, lejeczek wrote:
> 
> 
> On 01/07/16 12:41, Petr Vobornik wrote:
>> On 06/30/2016 04:56 PM, lejeczek wrote:
>>> ... its own FQHN and its IP ?
>>>
>>> hi users,
>>>
>>> I'm fiddling with rewrites but being an amateur cannot figure it out,
>>> it's on a multi/home-IP box. Is it possible?
>>>
>>> many thanks,
>>>
>>> L.
>>>
>> Hi L.
>>
>> Could you describe your environment and use case in more details. It is
>> not clear to me what you are trying to achieve or what doesn't work for you.
>>
>> Thank you
> gee, I though my scenario would be quite common among users,
> take a box with more then one net ifs, or even multiple IPs - what would be
> nice to have is fIPA webui resides/runs only on that FQHN and that IP to which
> hostname resolves. Eg, here is one single system:
> box1.my.dom.local 10.10.1.1 (eg, I go to https://10.10.1.1/)
> ipa.my.dom.local 10.10.1.2
> currently I get fIPA's webui everywhere, but I'd like it to be only at
> ipa.my.dom.local 10.10.1.2 (either if I URL via hostname or IP)
> I think it would be great to have included (maybe as comments/options) this in
> Apache's configs of IPA furure releases, if possible.
> Is it possible to construct such rules? Or there is different, simpler way?

I'm still trying to understand your use-case. Why exactly you need to limit
the web UI to one 'host name' while keeping it on the same box?


-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] webmaster permission

[Petr Spacek]

On 1.7.2016 13:35, Günther J. Niederwimmer wrote:
> Hello,
> 
> I am a newbie with IPA and have big Problems ;-),
> the "normal" Installation is working nice. :-))
> 
> But now I have a Problem ?
> 
> CentOS 7.2 IPA 4.3.1
> 1 Server (extern) with Virtual Systems (KVM) installed.
> DNSserver, Mailserver, Ipaserver,Webserver..
> 
> Now we like to have our Websystem on this Server
> 
> What is the best way to allow a external Webmaster to create or modify the 
> websites with joomla, and have the secure from IPA.
> 
> Have any a hint or link for this Problem. 

Hi,

it is strongly recommended to keep FreeIPA on a separate machine / VM and do
not mix it with anything else. FreeIPA should be considered as security centre
of your network and having additional applications under the same operating
system instance is potentially opening doors to attackers.

My recommendation is to install a seperate VM for FreeIPA and another separate
VM for other applications.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] SRV records?

[Petr Spacek]

On 30.6.2016 17:56, Christophe TREFOIS wrote:
> Hi,
> 
> I am getting a bit confused about what is possible / advised to do and how to 
> setup SRV records for our existing setup.
> 
> Currently, it looks like his:
> 
> ipa1.domain.ltd
> ipa2.domain.ltd
> ipa3.domain.ltd
> 
> I believe the installed domain and realm is domain.ltd (we added some other 
> realm domains later on).
> 
> And we use ipa1 for external user access, ipa2 for services, and ipa3 for 
> backup (not accessed directly).
> 
> We now want to create SRV records for this setup.
> 
> How would they look like?
> 
> The problem I have is that domain.ltd is also the university’s AD domain and, 
> according to the docs, it is not recommended to do this, in any fashion.
> 
> Would it be however, feasible, to do this via a FreeIPA-FreeIPA migration?
> 
> Could you please share any piece of information, or dadvice on this?

Unfortunately there is no way to make this work. There will be inevitable
conflicts on DNS and Kerberos level.

Please make sure you fully read
http://www.freeipa.org/page/Deployment_Recommendations
and
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#server-prereqs

After that the only option is to plan for new FreeIPA installation and
migration. Unfortunately complete FreeIPA-FreeIPA migration is not supported
either so it is mostly manual process (using hand-made scripts for your
deployment).

Do not hesitate to contact us if you have any questions.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] AES reverse encryption plugin on userPassword attribute

[Petr Spacek]

On 30.6.2016 15:30, opensauce . wrote:
> Hi All,
> 
> I need to store user passwords with reverse encryption for an application.
> 
> I know the AES plugin is enabled and available :
> 
> # AES, Password Storage Schemes, plugins, config
> dn: cn=AES,cn=Password Storage Schemes,cn=plugins,cn=config
> cn: AES
> nsslapd-pluginDescription: AES storage scheme plugin
> nsslapd-pluginEnabled: on
> nsslapd-pluginId: aes-storage-scheme
> nsslapd-pluginInitfunc: aes_init
> nsslapd-pluginPath: libpbe-plugin
> nsslapd-pluginType: reverpwdstoragescheme
> nsslapd-pluginVendor: 389 Project
> nsslapd-pluginVersion: 1.3.4.0
> nsslapd-pluginarg0: nsmultiplexorcredentials
> nsslapd-pluginarg1: nsds5ReplicaCredentials
> nsslapd-pluginprecedence: 1
> objectClass: top
> objectClass: nsSlapdPlugin
> objectClass: extensibleObject
> 
> How do I apply this plugin to the userPassword attribute of a single or
> multiple users?

Generally FreeIPA tries to hide passwords as much as possible even from admins
so this is not enabled by default. You might try to experiment using 389 DS
documentation [1] but there are no guarantees.

[1] 
http://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project