Re: [Freeipa-users] IPA - Password time outs / failures on trusted AD Users

[Alexander Bokovoy]

On Tue, 14 Jun 2016, David Fischer wrote:

Alexander,

I am getting the windows admin to refresh our DR AD setup and I should
be able to give you an idea on some of our groups layouts.

So a quick understanding is that a single user can have 15-20+ groups
those groups might have all users in them plus groups. The groups of
groups can link back to groups that the user may have already assigned.
We do know that we have atleast one circular group in our environment.
I have used the 'ignore_group_members' with some success. Ref:
https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/

That article is what Jakub and I wrote. Jakub may have more suggestions
and there are some improvements in recent SSSD releases in RHEL 7.2.4.

--
/ Alexander Bokovoy

--
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 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  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  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 the zone and recreating
 it.

 I am at a loss. What can be the issue here?

 Thanks,
 Nuno


 -Original Message-
 From: freeipa-users-boun...@redhat.com
 [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Petr Spacek
 Sent: segunda-feira, 13 de junho de 2016 06:50
 To: freeipa-users@redhat.com
 Subject: Re: [Freeipa-users] Error with DNS forwarding on replica.

 On 12.6.2016 20:47, Nuno Higgs wrote:
> Hello all,
>
>
>
> I have a IPA server - IPA 4.2 - and i have added a new IPA to 
> geographic replication.
>
>
>
> I have added it as stated in the documentation here:
>  x/7/ht 
> ml/Linux_Domain_Identity_Authentication_and_Policy_Guide/creating-the-
> replic
> a.html#replica-install-with-dns>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux
> /7/htm 
> l/Linux_Domain_Identity_Authentication_and_Policy_Guide/creating-the-r
> eplica
> .html#replica-install-with-dns
>
>
>
> All was replicated correctly, and i can do a kinit user@DOMAIN with 
> success within the replica.
>
> However there is a problem with the DNS sections:
>
>
>
> Although it DNS is ok, my configuration within IPA on the first server 
> regarding DNS zones that are set on forward only are not.
>
> In my first server, i can do a forward of domain - let's say 
>  domain.eu. On the second server (replica) the 
> forward is shown configured correctly within the webgui but it does 
> not work, giving a NX error on query   
> www.domain.eu (the A Record exists and is shown on the first server). 
> It also shows on dig on the replica (dig @x.x.x.x www.domain.eu), so it
 isn't a network permissions issue.
>
>
>
> I have deleted the zone on the master (and replica), and recreated it. 
> On the first server, it worked fine. On the replica the problem persisted.
>
>
>
> Am I missing anything? Is there a undocumented trick, or have i missed 
> something?
>

[Freeipa-users] Unable to install replica using replica file

[Abhijeet Kasurde]

Hi All,

I am creating master replica setup using following commands and getting 
error on replica server


2016-06-15T03:53:31Z DEBUG The ipa-replica-install command failed, 
exception: NetworkError: cannot connect to 
'ldaps://dhcp201-141.testrelm.test:636': TLS error -8157:Certificate 
extension not found.


Can anyone explain me what does this error is trying to say ?

I am performing following steps

$ mkdir /tmp/nssdb
$ vim /tmp/nssdb/password.txt
$ vim /tmp/nssdb/noise.txt
$ certutil -d /tmp/nssdb/ -N -f /tmp/nssdb/password.txt
$ certutil -d /tmp/nssdb -S -n ca -s cn=Test_CA -x -t CTu,Cu,Cu -g 2048 
-v 60 -z /tmp/nssdb/noise.txt -2 -f /tmp/nssdb/passwd.txt
$ certutil -d /tmp/nssdb -S -n server -s cn=dhcp201-172.testrelm.test -t 
,, -z /tmp/nssdb/noise.txt -c ca -f /tmp/nssdb/passwd.txt
$ /usr/bin/pk12util -o /tmp/nssdb/server.p12 -n server -d /tmp/nssdb -k 
/tmp/nssdb/passwd.txt -W Secret123
$ ipa-server-install --http-cert-file /tmp/nssdb/server.p12 
--dirsrv-cert-file /tmp/nssdb/server.p12 --ip-address 10.65.210.89 -r 
TESTRELM.TEST -p Secret123 -a Secret123 --setup-dns --forwarder 
10.11.5.19 --http-pin Secret123 --dirsrv-pin Secret123 -U
$ certutil -d /tmp/nssdb -S -n ca -s cn=Test_CA -x -t CTu,Cu,Cu -g 2048 
-v 60 -z /tmp/nssdb/noise.txt -2 -f /tmp/nssdb/passwd.txt -m 3
$ certutil -d /tmp/nssdb -S -n replica -s cn=dhcp201-141.testrelm.test 
-t ,, -z /tmp/nssdb/noise.txt -c ca -f /tmp/nssdb/passwd.txt -m 4
$ /usr/bin/pk12util -o /tmp/nssdb/replica.p12 -n replica -d /tmp/nssdb 
-k /tmp/nssdb/passwd.txt -W Secret123·
$ ipa-replica-prepare dhcp201-141.testrelm.test --http_pkcs12 
/tmp/nssdb/replica.p12 --http_pin Secret123 --dirsrv_pkcs12 
/tmp/nssdb/replica.p12 --dirsrv_pin Secret123 --ip-address 10.65.210.91 
--reverse-zone=210.65.10.in-addr.arpa.
$ scp /var/lib/ipa/replica-info-dhcp201-141.testrelm.test.gpg 
r...@dhcp201-141.testrelm.test:/root/


Attaching console.log and replicainstall.log

--
Thanks,
Abhijeet Kasurde

IRC: akasurde
http://akasurde.github.io

# ipa-replica-install --setup-dns --no-forwarders --password=Secret123 --admin-password=Secret123 --mkhomedir --unattended replica-info-dhcp201-141.testrelm.test.gpg 
Using reverse zone(s) 210.65.10.in-addr.arpa.
Run connection check to master
Check connection from replica to remote master 'dhcp201-172.testrelm.test':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

The following list of ports use UDP protocol and would need to be
checked manually:
   Kerberos KDC: UDP (88): SKIPPED
   Kerberos Kpasswd: UDP (464): SKIPPED

Connection from replica to master is OK.
Start listening on required ports for remote master check
Get credentials to log in to remote master
Check SSH connection to remote master
Execute check on remote master
Check connection from master to remote replica 'dhcp201-141.testrelm.test':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos KDC: UDP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   Kerberos Kpasswd: UDP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

Connection from master to replica is OK.

Connection check OK
Configuring NTP daemon (ntpd)
  [1/4]: stopping ntpd
  [2/4]: writing configuration
  [3/4]: configuring ntpd to start on boot
  [4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv). Estimated time: 1 minute
  [1/38]: creating directory server user
  [2/38]: creating directory server instance
  [3/38]: adding default schema
  [4/38]: enabling memberof plugin
  [5/38]: enabling winsync plugin
  [6/38]: configuring replication version plugin
  [7/38]: enabling IPA enrollment plugin
  [8/38]: enabling ldapi
  [9/38]: configuring uniqueness plugin
  [10/38]: configuring uuid plugin
  [11/38]: configuring modrdn plugin
  [12/38]: configuring DNS plugin
  [13/38]: enabling entryUSN plugin
  [14/38]: configuring lockout plugin
  [15/38]: creating indices
  [16/38]: enabling referential integrity plugin
  [17/38]: configuring ssl for ds instance
  [18/38]: configuring certmap.conf
  [19/38]: configure autobind for root
  [20/38]: configure new location for managed entries
  [21/38]: configure dirsrv ccache
  [22/38]: enable SASL mapping fallback
  [23/38]: restarting directory server
  [24/38]: setting up initial replication
  [error] NetworkError: cannot connect to 'ldaps://dhcp201-141.testrelm.test:636': TLS error -8157:Certificate extension not found.
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(Replica): ERRORcannot connect to 'ldaps://dhcp201-141.testrelm.test:636': TLS error -8157:Certificate extension not found.
2016-06-15T04:26:56Z DEBUG Logging to /var/log/ipareplica-i

Re: [Freeipa-users] IPA - Password time outs / failures on trusted AD Users

[David Fischer]

Alexander,

I am getting the windows admin to refresh our DR AD setup and I should be able 
to give you an idea on some of our groups layouts.

So a quick understanding is that a single user can have 15-20+ groups those 
groups might have all users in them plus groups. The groups of groups can link 
back to groups that the user may have already assigned.
We do know that we have atleast one circular group in our environment.
I have used the 'ignore_group_members' with some success. Ref: 
https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/



-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com]
Sent: Tuesday, June 14, 2016 1:03 PM
To: David Fischer
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] IPA - Password time outs / failures on trusted AD 
Users

On Tue, 14 Jun 2016, David Fischer wrote:
>Alexander,
>One of the things I am seeing is that our AD has groups that are 5 deep
>and IPA is not able to enumerate all the groups  Is there away to help
>IPA in search depth or scope?
SSSD should be able to handle that. If not, show the logs that demonstrate 
specific issues with a model group.

--
/ Alexander Bokovoy

#
The information contained in this electronic mail message, including 
attachments, if any, is PetSmart confidential information.  It is intended only 
for the use of the person(s) named above.  If the reader of this message is not 
the intended recipient, or has received this message in error, you are hereby 
notified that any review, dissemination, distribution or copying of this 
communication is strictly prohibited.  If you are not the intended recipient or 
have received this message in error, please notify the sender via e-mail and 
promptly delete the original message.
#

-- 
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

[Freeipa-users] Replicas in different AWS Regions

[Steve Viola]

Hello,

I'm setting up a freeIPA replica topology in AWS, and need to have replicas
in different regions, and clients will be in different regions. The IPA
servers will have an external IP, but the hostname of the servers are going
to resolve to the internal IP. I am going to have a domain name for both
the internal and external address, such as ipa01.internal.example.com and
ipa01.public.example.com respectivly.

When preparing the replica for a server in another region, I make sure the
connection check works when using the public domain name (
ipa01.public.example.com), and create the replica file. When installing the
file on the replica, it stops, with the following error message:

This replica was created for 'ipa01.public.example.com' but this machine is
> named ipa01.internal.example.com'


I can get around this by editing /etc/hosts, and I guess I could set up
different DNS Views for different regions, but in reading the freeIPA
documentation
, DNS
Views / Split Horizon are not recommended. What's the recommended procedure
for a setup like this?

Can anyone point me to documentation that will solve my problem? Has anyone
done a cross-region AWS replication setup?

Thanks

-- 
Steven Viola
-- 
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 - Password time outs / failures on trusted AD Users

[Alexander Bokovoy]

On Tue, 14 Jun 2016, David Fischer wrote:

Alexander,
One of the things I am seeing is that our AD has groups that are 5 deep
and IPA is not able to enumerate all the groups  Is there away to help
IPA in search depth or scope?

SSSD should be able to handle that. If not, show the logs that
demonstrate specific issues with a model group.

--
/ Alexander Bokovoy

--
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 - Password time outs / failures on trusted AD Users

[David Fischer]

Alexander,
One of the things I am seeing is that our AD has groups that are 5 deep and IPA 
is not able to enumerate all the groups  Is there away to help IPA in search 
depth or scope?

-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com]
Sent: Monday, June 13, 2016 12:07 PM
To: David Fischer
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] IPA - Password time outs / failures on trusted AD 
Users

On Mon, 13 Jun 2016, David Fischer wrote:
>(Note: versions below)
>
>All,
>I am getting password failures for accounts coming from a sub-ad domain.
>I originally was not able to do 'getent' lookups of random users or groups and 
>found that it was timing out during ldap scan. I upped the timeout on the 'IPA 
>Configuration' tab in the web interface and this solved the 'getent' issue.  
>Now I am able to do 'getent' passwd on all users in a sub-ad domain
>
>My new problem is that I am now unable to use password to login.  If I grab a 
>kerberos ticket I am able to just ssh into any IPA unix system, but fails when 
>trying to do a password lookup.
>
>the layout of systems are as follows:
>
>1) forest domain with no users or groups
>2) child domain with all users and groups.
>3) IPA Realm/Domain trusted to forest domain
>
>All users are in a sub-OU below the top of the domain in a OU called Users.  
>There are about 11K users in this OU. but lookups seam really slow.
>
>I have added to  sssd.conf the following
>1) lookup_family_order = ipv4_only
>2) ignore_group_members=True
>3) ldap_purge_cache_timeout=0
>4) subdomain_inherit = ignore_group_members, ldap_purge_cache_timeout
>5) debug_level=9
>
>Could anyone help direct me to a place to start looking for why lookups are 
>slow and passwords are not being allowed?
Start with 
http://scanmail.trustwave.com/?c=6406&d=9ITf1_A7P_gkm18DVpKbEy7lQ6ga7hwK2wRD_04F5w&u=https%3a%2f%2ffedorahosted%2eorg%2fsssd%2fwiki%2fTroubleshooting
--
/ Alexander Bokovoy

#
The information contained in this electronic mail message, including 
attachments, if any, is PetSmart confidential information.  It is intended only 
for the use of the person(s) named above.  If the reader of this message is not 
the intended recipient, or has received this message in error, you are hereby 
notified that any review, dissemination, distribution or copying of this 
communication is strictly prohibited.  If you are not the intended recipient or 
have received this message in error, please notify the sender via e-mail and 
promptly delete the original message.
#

-- 
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] CA: IPA certificates not renewing

[Marc Wiatrowski]

On Tue, Jun 14, 2016 at 11:22 AM, Rob Crittenden 
wrote:

> Marc Wiatrowski wrote:
>
>> Hello, I'm having issues with the 3 ipa certificates of type CA: IPA
>> renewing on 2 of 3 replicas.  Particularly on the 2 that are not the CA
>> master.  The other 5 certificates from getcert list do renew and all
>> certificates on the CA master do look to renew.
>>
>> Both servers running ipa-server-3.0.0-50.el6.centos.1.x86_64  I've done
>> full updates and rebooted.
>>
>
> Can you check on the replication status for each CA?
>
> $ ipa-csreplica-manage list -v ipa.example.com
>
> The hostname is important because including that will show the agreements
> that host has. Do this for each master with a CA.
>
> The CA being asked to do the renewal is unaware of the current serial
> number so it is refusing to proceed.
>
> rob
>
>

[root@spider01o]$ ipa-csreplica-manage list -v spider01a.iglass.net
Directory Manager password:

spider01b.iglass.net
  last init status: None
  last init ended: None
  last update status: 0 Replica acquired successfully: Incremental update
succeeded
  last update ended: 2016-06-14 17:49:16+00:00
spider01o.iglass.net
  last init status: None
  last init ended: None
  last update status: 0 Replica acquired successfully: Incremental update
started
  last update ended: 2016-06-14 17:55:20+00:00

[root@spider01o]$ ipa-csreplica-manage list -v spider01o.iglass.net
Directory Manager password:

spider01a.iglass.net
  last init status: None
  last init ended: None
  last update status: 0 Replica acquired successfully: Incremental update
started
  last update ended: 2016-06-14 17:57:44+00:00
spider01b.iglass.net
  last init status: None
  last init ended: None
  last update status: 0 Replica acquired successfully: Incremental update
started
  last update ended: 2016-06-14 17:57:41+00:00

[root@spider01o]$ ipa-csreplica-manage list -v spider01b.iglass.net
Directory Manager password:

spider01a.iglass.net
  last init status: 0 Total update succeeded
  last init ended: 2016-06-03 19:43:12+00:00
  last update status: 0 Replica acquired successfully: Incremental update
succeeded
  last update ended: 2016-06-14 17:44:17+00:00
spider01o.iglass.net
  last init status: 0 Total update succeeded
  last init ended: 2016-06-03 19:44:38+00:00
  last update status: 0 Replica acquired successfully: Incremental update
started
  last update ended: 2016-06-14 17:57:53+00:00
spider01a.iglass.net
  last init status: None
  last init ended: None
  last update status: 0 Replica acquired successfully: Incremental update
succeeded
  last update ended: 2016-06-14 17:44:13+00:00
spider01o.iglass.net
  last init status: None
  last init ended: None
  last update status: 0 Replica acquired successfully: Incremental update
started
  last update ended: 2016-06-14 17:57:54+00:00


Not sure what this is telling... This an issue with the last being
doubled?  Thanks
-- 
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

[Freeipa-users] Best practices on securing freeipa

[Danila Ladner]

Greetings Folks.
I could not find any information on best practices of securing free ipa
servers and its replicas.
Since the hosts become an important part of IT IM infrastructure, wanted to
see if anyone can point me to the right sources beyond default
configuration.
Thank you,
Danila
-- 
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.3.0] CentOS 6.8 sudo fails

[Lukas Slebodnik]

On (14/06/16 08:56), Jakub Hrozek wrote:
>On Mon, Jun 13, 2016 at 06:06:00PM -0400, Rob Crittenden wrote:
>> Nathan Peters wrote:
>> > I have confirmed that on both CentOS 6.8 and CentOS 6.7 that if the group 
>> > is a POSIX group, it can be used in sudo rules.
>> > If the group is a 'normal' group it will fail when used in sudo rules.
>> > 
>> > This is really silly because in a previous version of CentOS (6.3) sudo 
>> > rules would fail if the group was POSIX, and work if the group was 
>> > 'normal'.
>> > 
>> > I'm not sure when this changed because we still have CentOS 6.7 machines 
>> > that are working fine with the non posix groups.
>> > I did notice that in sssd 1.13.3-22.el6 sudo fails with non posix groups
>> > And with 1.12.4-47.el6_7.7 sudo works with non posix groups
>> > 
>> > So now FreeIPA exists in a really funky state where if you are below 
>> > CentOS 6.4 you MUST use non POSIX groups and If you are on CentOS 6.7 and 
>> > above, you must use POSIX groups.
>> > 
>> > So basically, you need to roll forward your entire infrastructure to 
>> > CentOS 6.7 or above or else your old machines will suddently start failing 
>> > sudo logins when you udate the groups or your new machines will simply 
>> > fail with groups that worked on your old ones.
>> > 
>> > Can you please confirm what the intended behavior is because I would 
>> > rather not go through the trouble of re-creating all our sudo / hbac rules 
>> > and user groups...
>> 
>> Jakub already stated that this would be bug if it only worked with POSIX
>> groups, so you've confirmed that.
>> 
>> If you have a Red Hat subscription I'd open a support case and ask to be
>> added to bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1336548
>
>Because that bug is private (sorry, there's some RH customer data there)
>and because you also confirmed it's an issue, I cloned the bugzilla to
>our upstream Trac:
>https://fedorahosted.org/sssd/ticket/3046
>
>I'm sceptical we will have a fix this week, we're trying to meet a
>deadline at the moment, but we will try to come up with a fix either late
>next week or the one after.
>
>I'm sorry about the inconvenience. I wonder if, as a temporary
>workaround, you could point sssd to the compat tree using
>ldap_sudo_search_base?
>
Yes, it worth a try.
We switched from compat search base to native search base for sudo
in 1.13.x

But many things were changed in sudo; it neend't help.

LS

-- 
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.

[Nuno Higgs]

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

Thanks,
Nuno

> On 14 Jun 2016, at 15:28, Petr Spacek  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  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 the zone and recreating
>>> it.
>>> 
>>> I am at a loss. What can be the issue here?
>>> 
>>> Thanks,
>>> Nuno
>>> 
>>> 
>>> -Original Message-
>>> From: freeipa-users-boun...@redhat.com
>>> [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Petr Spacek
>>> Sent: segunda-feira, 13 de junho de 2016 06:50
>>> To: freeipa-users@redhat.com
>>> Subject: Re: [Freeipa-users] Error with DNS forwarding on replica.
>>> 
>>> On 12.6.2016 20:47, Nuno Higgs wrote:
 Hello all,
 
 
 
 I have a IPA server - IPA 4.2 - and i have added a new IPA to 
 geographic replication.
 
 
 
 I have added it as stated in the documentation here:
 
 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux
 /7/htm 
 l/Linux_Domain_Identity_Authentication_and_Policy_Guide/creating-the-r
 eplica
 .html#replica-install-with-dns
 
 
 
 All was replicated correctly, and i can do a kinit user@DOMAIN with 
 success within the replica.
 
 However there is a problem with the DNS sections:
 
 
 
 Although it DNS is ok, my configuration within IPA on the first server 
 regarding DNS zones that are set on forward only are not.
 
 In my first server, i can do a forward of domain - let's say 
  domain.eu. On the second server (replica) the 
 forward is shown configured correctly within the webgui but it does 
 not work, giving a NX error on query   
 www.domain.eu (the A Record exists and is shown on the first server). 
 It also shows on dig on the replica (dig @x.x.x.x www.domain.eu), so it
>>> isn't a network permissions issue.
 
 
 
 I have deleted the zone on the master (and replica), and recreated it. 
 On the first server, it worked fine. On the replica the problem persisted.
 
 
 
 Am I missing anything? Is there a undocumented trick, or have i missed 
 something?
>>> 
>>> Hello,
>>> 
>>> it could be either a DNS configuration problem or a LDAP replication
>>> problem.
>>> 
>>> Please show us output from command:
>>> $ ipa dnsforwardzone-show domain.eu
>>> from all IPA servers you have.
>>> 
>>> The output should be the same. If it is not the same then you are most
>>> likely facing an replication problem, please see
>>> http://www.freeipa.org/page/

Re: [Freeipa-users] LDAP "mail" from User

[Peter Fern]

I wrote a plugin a long time ago for this, just put it on Github for you:

https://github.com/pdf/freeipa-user-mailalternateaddress

This adds support for the mailAlternateAddress (AKA alias) schema to the
GUI/CLI.

On 14/06/16 23:27, Günther J. Niederwimmer wrote:
> Hello, > > Is there a way to differ the Mail addresses from a user. > > I
setup a User with with 3 Mail addresses in IPA UI > > User: Peter > >
pe...@xxx.net > pe...@.com > pe...@.bbb > > for me, I can't
found a way to setup this correct in a dovecot way? > > I mean I must
have a "aliases" field in Ldap ? > > I am not a Ldap Profi ;-), but why
I can insert more EMail addresses when I > can't found this later. > >
Have any a answer for my problem, > > Thanks >


-- 
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] CA: IPA certificates not renewing

[Rob Crittenden]

Marc Wiatrowski wrote:

Hello, I'm having issues with the 3 ipa certificates of type CA: IPA
renewing on 2 of 3 replicas.  Particularly on the 2 that are not the CA
master.  The other 5 certificates from getcert list do renew and all
certificates on the CA master do look to renew.

Both servers running ipa-server-3.0.0-50.el6.centos.1.x86_64  I've done
full updates and rebooted.


Can you check on the replication status for each CA?

$ ipa-csreplica-manage list -v ipa.example.com

The hostname is important because including that will show the 
agreements that host has. Do this for each master with a CA.


The CA being asked to do the renewal is unaware of the current serial 
number so it is refusing to proceed.


rob



The failed renews look like:

[root@spider01a]$ getcert list -i 20141202144354
Number of certificates and requests being tracked: 8.
Request ID '20141202144354':
status: CA_UNREACHABLE
ca-error: Server at https://spider01a.iglass.net/ipa/xml failed request,
will retry: 4301 (RPC failed at server.  Certificate operation cannot be
completed: EXCEPTION (Certificate serial number 0x3ffe0010 not found)).
stuck: no
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=IGLASS.NET 
subject: CN=spider01a.iglass.net
,O=IGLASS.NET 
expires: 2016-12-02 14:38:45 UTC
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA
track: yes
auto-renew: yes

[root@spider01a]$ getcert list -i 20141202144616
Number of certificates and requests being tracked: 8.
Request ID '20141202144616':
status: CA_UNREACHABLE
ca-error: Server at https://spider01a.iglass.net/ipa/xml failed request,
will retry: 4301 (RPC failed at server.  Certificate operation cannot be
completed: EXCEPTION (Certificate serial number 0x3ffe000f not found)).
stuck: no
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-IGLASS-NET',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-IGLASS-NET/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/dirsrv/slapd-IGLASS-NET',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=IGLASS.NET 
subject: CN=spider01a.iglass.net
,O=IGLASS.NET 
expires: 2016-12-02 14:38:43 UTC
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv IGLASS-NET
track: yes
auto-renew: yes

[root@spider01a]$ getcert list -i 20141202144733
Number of certificates and requests being tracked: 8.
Request ID '20141202144733':
status: CA_UNREACHABLE
ca-error: Server at https://spider01a.iglass.net/ipa/xml failed request,
will retry: 4301 (RPC failed at server.  Certificate operation cannot be
completed: EXCEPTION (Certificate serial number 0x3ffe0011 not found)).
stuck: no
key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=IGLASS.NET 
subject: CN=spider01a.iglass.net
,O=IGLASS.NET 
expires: 2016-12-02 14:38:46 UTC
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_httpd
track: yes
auto-renew: yes


From
[root@spider01a]$ getcert resubmit -i 20141202144354

On the replica issuing the resubmit

==> /var/log/httpd/access_log <==
192.168.176.2 - - [13/Jun/2016:15:49:32 -0400] "POST /ipa/xml HTTP/1.1"
401 1370

==> /var/log/httpd/error_log <==
[Mon Jun 13 15:49:33 2016] [error] ipa: ERROR:
ipaserver.plugins.dogtag.ra.get_certificate(): EXCEPTION (Certificate
serial number 0x3ffe0010 not found)
[Mon Jun 13 15:49:33 2016] [error] ipa: INFO:
host/spider01a.iglass@iglass.net
:
cert_request(u'MIIDsTCCApkCAQAwNDETMBEGA1UEChMKSUdMQVNTLk5FVDEdMBsGA1UEAxMUc3BpZGVyMDFhLml...UVrN8lbKn17V5COjnj6k0mdbz3KptL0UI/l0BPlFBWGN5MFYaDx2F+y6LWv/aXeu2V4E6LA==',
principal=u'dogtagldap/spider01a.iglass@iglass.net
', add=True):
CertificateOperationError

==> /var/log/httpd/access_log <==
192.168.176.2 - - [13/Jun/2016:15:49:33 -0400] "POST
/ca/agent/ca/displayBySerial HTTP/1.1" 200 262
192.168.176.2 - host/spider01

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

[Petr Spacek]

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  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 the zone and recreating
>> it.
>>
>> I am at a loss. What can be the issue here?
>>
>> Thanks,
>> Nuno
>>
>>
>> -Original Message-
>> From: freeipa-users-boun...@redhat.com
>> [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Petr Spacek
>> Sent: segunda-feira, 13 de junho de 2016 06:50
>> To: freeipa-users@redhat.com
>> Subject: Re: [Freeipa-users] Error with DNS forwarding on replica.
>>
>> On 12.6.2016 20:47, Nuno Higgs wrote:
>>> Hello all,
>>>
>>>
>>>
>>> I have a IPA server - IPA 4.2 - and i have added a new IPA to 
>>> geographic replication.
>>>
>>>
>>>
>>> I have added it as stated in the documentation here:
>>> >> x/7/ht 
>>> ml/Linux_Domain_Identity_Authentication_and_Policy_Guide/creating-the-
>>> replic
>>> a.html#replica-install-with-dns>
>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux
>>> /7/htm 
>>> l/Linux_Domain_Identity_Authentication_and_Policy_Guide/creating-the-r
>>> eplica
>>> .html#replica-install-with-dns
>>>
>>>
>>>
>>> All was replicated correctly, and i can do a kinit user@DOMAIN with 
>>> success within the replica.
>>>
>>> However there is a problem with the DNS sections:
>>>
>>>
>>>
>>> Although it DNS is ok, my configuration within IPA on the first server 
>>> regarding DNS zones that are set on forward only are not.
>>>
>>> In my first server, i can do a forward of domain - let's say 
>>>  domain.eu. On the second server (replica) the 
>>> forward is shown configured correctly within the webgui but it does 
>>> not work, giving a NX error on query   
>>> www.domain.eu (the A Record exists and is shown on the first server). 
>>> It also shows on dig on the replica (dig @x.x.x.x www.domain.eu), so it
>> isn't a network permissions issue.
>>>
>>>
>>>
>>> I have deleted the zone on the master (and replica), and recreated it. 
>>> On the first server, it worked fine. On the replica the problem persisted.
>>>
>>>
>>>
>>> Am I missing anything? Is there a undocumented trick, or have i missed 
>>> something?
>>
>> Hello,
>>
>> it could be either a DNS configuration problem or a LDAP replication
>> problem.
>>
>> Please show us output from command:
>> $ ipa dnsforwardzone-show domain.eu
>> from all IPA servers you have.
>>
>> The output should be the same. If it is not the same then you are most
>> likely facing an replication problem, 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

[Freeipa-users] LDAP "mail" from User

[Günther J . Niederwimmer]

Hello,

Is there a way to differ the Mail addresses from a user.

I setup a User with with 3 Mail addresses in IPA UI

User: Peter

pe...@xxx.net
pe...@.com
pe...@.bbb

for me, I can't found a way to setup this correct in a dovecot way?

I mean I must have a "aliases" field in Ldap ?

I am not a Ldap Profi ;-), but why I can insert more EMail addresses when I 
can't found this later.

Have any a answer for my problem,

Thanks
 
-- 
mit freundlichen Grüßen / best regards,

  Günther J. Niederwimmer

-- 
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: ERROR: invalid 'hostname': invalid domain-name: only letters, numbers, '-' are allowed. DNS label may not start or end with '-'

[Łukasz Jaworski]

Thanks.

Best regards,
Ender

Wiadomość napisana przez Rob Crittenden  w dniu 14 cze 
2016, o godz. 13:56:

> Łukasz Jaworski wrote:
>> Hi,
>> 
>> freeipa-client-4.2.4-1.fc23.x86_64 freeipa-server-4.2.4-1.fc23.x86_64
>> 
>> I've tried add hostname with multiple hyphens. Sth like:
>> example--name-of-host.example.com. Output is: ipa: ERROR: invalid
>> ‘hostname’: invalid domain-name: only letters, numbers, ‘-’ are allowed.
>> DNS label may not start or end with ‘-’
>> 
>> IMHO hyphens are not allowed: the first and last characters of a label
>> (RFC 952 and 1123)
>> 
>> If I'm right, in validate_dns_label (util.py) should be something like this:
>> 
>> 
>>  diff util.py util.py.corrected 225c225 < label_regex =
>>  
>> r'^[%(base)s%(extra)s]([%(base)s%(extra)s%(middle)s]?[%(base)s%(extra)s])*$'
>>  \
>> 
>>label_regex =
>>
>> r'^[%(base)s%(extra)s]([%(base)s%(extra)s%(middle)s]+?[%(base)s%(extra)s])*$'
>>\
> 
> See 
> https://u2049412.ct.sendgrid.net/wf/click?upn=d8cswn-2BnEH-2B7WbzLTEgT0E1WY4setDHks-2BN0BaUeSRkffPOVmnu1j4NL5AZQSJz11-2BIlHFn-2BrzA2teewCcbEdg-3D-3D_an4-2Fi8Vk1W4hjXglTw5zijKXOIRderaI8LFDnF-2FT8B3V92yGlXo2OZHI8jnDj-2F4GSfoAeql5dkDdLpSdNoo-2BLrNmlfLJCTDqx2vIUS5iVOhvTPQEdtjoftVAz03IHNlO5HSli58l2DF6kpdgY7paaTVkbt70zgAI2bXtgtCjg1m7g7VRTyPTS9YXtJTrNXb-2B9GVDSMNn-2B8MiT-2FDUXEFjYucsxyrrqi7VrCmfGQOtuEM-3D
> 
> rob

-- 
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: ERROR: invalid 'hostname': invalid domain-name: only letters, numbers, '-' are allowed. DNS label may not start or end with '-'

[Rob Crittenden]

Łukasz Jaworski wrote:

Hi,

freeipa-client-4.2.4-1.fc23.x86_64 freeipa-server-4.2.4-1.fc23.x86_64

I've tried add hostname with multiple hyphens. Sth like:
example--name-of-host.example.com. Output is: ipa: ERROR: invalid
‘hostname’: invalid domain-name: only letters, numbers, ‘-’ are allowed.
DNS label may not start or end with ‘-’

IMHO hyphens are not allowed: the first and last characters of a label
(RFC 952 and 1123)

If I'm right, in validate_dns_label (util.py) should be something like this:


  diff util.py util.py.corrected 225c225 < label_regex =
  
r'^[%(base)s%(extra)s]([%(base)s%(extra)s%(middle)s]?[%(base)s%(extra)s])*$'
  \

label_regex =

r'^[%(base)s%(extra)s]([%(base)s%(extra)s%(middle)s]+?[%(base)s%(extra)s])*$'
\


See https://fedorahosted.org/freeipa/ticket/4710

rob

--
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 renew kerberos tickets without user intervation?

[Rob Crittenden]

Matrix wrote:

HI, All

IPA server was installed on ipaserver.dev.example.net

A user 'ads' in IPA will periodically 'rsync' files from ipaclient1 to
ipaclient2. I found that rsync cronjobs will be failed once 'ads'
kerberos ticket has been expired.

I would like to renew kerberos tickets before expiration without user
intervation, but failed.

krb configuration:

# cat /etc/krb5.conf
includedir /var/lib/sss/pubconf/krb5.include.d/

[logging]
  default = FILE:/var/log/krb5libs.log
  kdc = FILE:/var/log/krb5kdc.log
  admin_server = FILE:/var/log/kadmind.log

[libdefaults]
  default_realm = EXAMPLE.NET
  dns_lookup_realm = false
  dns_lookup_kdc = true
  rdns = false
  ticket_lifetime = 24h
  forwardable = yes
  udp_preference_limit = 0
  default_ccache_name = KEYRING:persistent:%{uid}
  renew_lifetime = 7d

[realms]
  EXAMPLE.NET = {
   kdc = ipaserver.dev.example.net:88
   master_kdc = ipaserver.dev.example.net:88
   admin_server = ipaserver.dev.example.net:749
   default_domain = example.net
   pkinit_anchors = FILE:/etc/ipa/ca.crt
}

[domain_realm]
  .example.net = EXAMPLE.NET
  example.net = EXAMPLE.NET

[dbmodules]
   EXAMPLE.NET = {
 db_library = ipadb.so
   }

When I was trying to renew kerberos ticket from client1, error message
was shown as :
$ kinit -R
kinit: KDC can't fulfill requested option while renewing credentials

And logs from ipa server:
# tailf /var/log/krb5kdc.log
..
Jun 14 06:22:35 ipaserver.dev.example.net krb5kdc[23368](info): TGS_REQ
(6 etypes {18 17 16 23 25 26}) 192.168.11.235: TICKET NOT RENEWABLE:
authtime 0,  a...@example.net for krbtgt/example@example.net, KDC
can't fulfill requested option
Jun 14 06:22:35 ipaserver.dev.example.net krb5kdc[23368](info): closing
down fd 10
..

any suggestions would be appreciated.



Please see the list archives, for example 
https://www.redhat.com/archives/freeipa-users/2016-June/msg00176.html


rob

--
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.

[Nuno Higgs]

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.

Thanks for your help!
Nuno

> On 13 Jun 2016, at 10:14, Nuno Higgs  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 the zone and recreating
> it.
> 
> I am at a loss. What can be the issue here?
> 
> Thanks,
> Nuno
> 
> 
> -Original Message-
> From: freeipa-users-boun...@redhat.com
> [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Petr Spacek
> Sent: segunda-feira, 13 de junho de 2016 06:50
> To: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Error with DNS forwarding on replica.
> 
> On 12.6.2016 20:47, Nuno Higgs wrote:
>> Hello all,
>> 
>> 
>> 
>> I have a IPA server - IPA 4.2 - and i have added a new IPA to 
>> geographic replication.
>> 
>> 
>> 
>> I have added it as stated in the documentation here:
>> > x/7/ht 
>> ml/Linux_Domain_Identity_Authentication_and_Policy_Guide/creating-the-
>> replic
>> a.html#replica-install-with-dns>
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux
>> /7/htm 
>> l/Linux_Domain_Identity_Authentication_and_Policy_Guide/creating-the-r
>> eplica
>> .html#replica-install-with-dns
>> 
>> 
>> 
>> All was replicated correctly, and i can do a kinit user@DOMAIN with 
>> success within the replica.
>> 
>> However there is a problem with the DNS sections:
>> 
>> 
>> 
>> Although it DNS is ok, my configuration within IPA on the first server 
>> regarding DNS zones that are set on forward only are not.
>> 
>> In my first server, i can do a forward of domain - let's say 
>>  domain.eu. On the second server (replica) the 
>> forward is shown configured correctly within the webgui but it does 
>> not work, giving a NX error on query   
>> www.domain.eu (the A Record exists and is shown on the first server). 
>> It also shows on dig on the replica (dig @x.x.x.x www.domain.eu), so it
> isn't a network permissions issue.
>> 
>> 
>> 
>> I have deleted the zone on the master (and replica), and recreated it. 
>> On the first server, it worked fine. On the replica the problem persisted.
>> 
>> 
>> 
>> Am I missing anything? Is there a undocumented trick, or have i missed 
>> something?
> 
> Hello,
> 
> it could be either a DNS configuration problem or a LDAP replication
> problem.
> 
> Please show us output from command:
> $ ipa dnsforwardzone-show domain.eu
> from all IPA servers you have.
> 
> The output should be the same. If it is not the same then you are most
> likely facing an replication problem, 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
> 
> -- 
> 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

-- 
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] What id my AD domain user password not available

[Alexander Bokovoy]

On Tue, 14 Jun 2016, Ben .T.George wrote:

HI

sorry it was issue with DNS (SRV records was missing) and it's been fixed
now. i have created one way forest trust

While issuing trust from IPA server, i have used shared key and the process
was successful.

It will always be successful because IPA server talks to itself.


But after validating the trust from AD side, it's asking for some username
and  password.I have gave below password combinations:

IPA "admin" user and password
IPA admin user and IPA directory password
AD "Administrator" and password.

but still it's not accepting that. So which username and password it is
expecting?

This is if i create one way trust. If i create two way trust, this password
is not asking. and my AD admin will only allow one way trust.

There is a bug right now where shared secret one-way trust is broken
with the symptoms your setup is showing.

You have four options:
- one-way trust established using credentials of AD administrator who
  is member of Enterprise Admins or Domain admins group from the forest
  root domain. This options works just fine.

- one-way trust established using shared secret. This doesn't currently
  work. https://bugzilla.redhat.com/show_bug.cgi?id=1345975

- two-way trust established using credentials of AD administrator who
  is member of Enterprise Admins of Domain admins group from the forest
  root domain. This option works just fine.

- two-way trust established using shared secret. This option works just
  fine.

I'm currently looking into bug #1345975.
--
/ Alexander Bokovoy

--
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.3.0] CentOS 6.8 sudo fails

[Jakub Hrozek]

On Mon, Jun 13, 2016 at 06:06:00PM -0400, Rob Crittenden wrote:
> Nathan Peters wrote:
> > I have confirmed that on both CentOS 6.8 and CentOS 6.7 that if the group 
> > is a POSIX group, it can be used in sudo rules.
> > If the group is a 'normal' group it will fail when used in sudo rules.
> > 
> > This is really silly because in a previous version of CentOS (6.3) sudo 
> > rules would fail if the group was POSIX, and work if the group was 'normal'.
> > 
> > I'm not sure when this changed because we still have CentOS 6.7 machines 
> > that are working fine with the non posix groups.
> > I did notice that in sssd 1.13.3-22.el6 sudo fails with non posix groups
> > And with 1.12.4-47.el6_7.7 sudo works with non posix groups
> > 
> > So now FreeIPA exists in a really funky state where if you are below CentOS 
> > 6.4 you MUST use non POSIX groups and If you are on CentOS 6.7 and above, 
> > you must use POSIX groups.
> > 
> > So basically, you need to roll forward your entire infrastructure to CentOS 
> > 6.7 or above or else your old machines will suddently start failing sudo 
> > logins when you udate the groups or your new machines will simply fail with 
> > groups that worked on your old ones.
> > 
> > Can you please confirm what the intended behavior is because I would rather 
> > not go through the trouble of re-creating all our sudo / hbac rules and 
> > user groups...
> 
> Jakub already stated that this would be bug if it only worked with POSIX
> groups, so you've confirmed that.
> 
> If you have a Red Hat subscription I'd open a support case and ask to be
> added to bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1336548

Because that bug is private (sorry, there's some RH customer data there)
and because you also confirmed it's an issue, I cloned the bugzilla to
our upstream Trac:
https://fedorahosted.org/sssd/ticket/3046

I'm sceptical we will have a fix this week, we're trying to meet a
deadline at the moment, but we will try to come up with a fix either late
next week or the one after.

I'm sorry about the inconvenience. I wonder if, as a temporary
workaround, you could point sssd to the compat tree using
ldap_sudo_search_base?

-- 
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