Re: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records

2017-02-09 Thread Ben Roberts 
Hi Martin,

> I'm not sure how your DNS data are structured, but usually (properly)
> DS record is located in parent zone, so AXFR for
> subdomain.exmale.com should not return DS record, but AXFR
> for example.com should return DS record of
> subdomain.example.com.

Herein lies the problem. The nameservers are authoritative for both
the parent and child zones, and both are replicated from the primaries
to the secondary nameserver. The DS glue records for the child zone
contained within the parent zone are not being replicated across to
the secondary via AXFR. Thus there is a complete chain for DNSSEC
trust when queries are directed at the primaries, but not when queries
are directed at the secondary nameserver.

This affects both the DS glue records, and also the apex DS records
which don't need to be present, but which bind-dyndb-ldap makes
available automatically anyway. I raise this not because it's needed,
but it might be relevant to identifying where the root cause is.

Regards,
Ben Roberts

-- 
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, AXFR and DS records

2017-02-09 Thread Martin Basti 
Hello, 

I'm not sure how your DNS data are structured, but usually (properly) DS record 
is located in parent zone, so AXFR for subdomain.exmale.com should not return 
DS record, but AXFR for example.com should return DS record of 
subdomain.example.com.

Martin

- Original Message -
From: "Ben Roberts" 
To: "Tomas Krizek" 
Cc: freeipa-users@redhat.com
Sent: Thursday, February 9, 2017 10:53:38 AM
Subject: Re: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records

Hi Tomas,

> when I add a DS record to LDAP (without any DNSSEC configuration),
> it is included in my AXFR transfer. I'm using bind-dyndb-ldap-10.1.
>
> I suppose you have DNSSEC configured. Could you be affected by the
> limitations mentioned in [1]?

Yes, dnssec is otherwise fully configured (the only bit I don't yet
have is the DS records for the "example.local" parent domain
registered upstream, but that shouldn't have any impact here. I don't
think the linked limitations apply, I'm not attempting to use the CDS
or CDNSKEY record types, and am manually specifying the DS records for
the child zone.

This is with bind 9.11 and bind-dyndb-ldap 11.0.

Regards,
Ben Roberts

-- 
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] Cross domain or pass through authentication v4.4

2017-02-09 Thread Alexander Bokovoy 

On to, 09 helmi 2017, Munoz, Ian A wrote:

Hello,

I can't seem to set up or find decent documentation on either
cross-domain or pass through authentication. I have tried kerberos
cross realm, and saslauthd.

I have two different scenarios I would like to potentially accomplish.

1. FreeIPA domain of a.example.tld pass through authentication to FreeIPA 
domain b.example.tld

There is no support for IPA-IPA trust currently.


2. FreeIPA a.example.tld needs to pass through authentication to our
enterprise ldap

There is no support for this either.



What is the correct documentation to be following? Should I be trying
to achieve this via an openldap pass through or a kerberos cross realm
trust?

The only supported configuration for authenticating externally defined
users is when they are part of Active Directory domain. In such case
establishing forest trust to Active Directory is the right thing to do.
Please note that it is not just a Kerberos cross realm trust, so don't
try that option on Active Directory side, it will not work against
FreeIPA.



--
/ 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] CA not found?

2017-02-09 Thread Guillermo Fuentes 
As we're enforcing encryption, here is via ldaps:
$ ldapsearch -H ldaps://`hostname` -D "cn=Directory Manager"  -W -s
sub -b ou=authorities,ou=ca,o=ipaca   Enter LDAP
Password:
# extended LDIF
#
# LDAPv3
# base

Re: [Freeipa-users] CA not found?

2017-02-09 Thread Fraser Tweedale 
On Thu, Feb 09, 2017 at 06:27:12PM -0500, Guillermo Fuentes wrote:
> Hi Fraser,
> 
> The cluster was migrated from FreeIPA 3 (CentOS 6) to FreeIPA 4
> (CentOS 7) a year ago.
> 
> - Output of 'ldapsearch -s sub -b ou=authorities,ou=ca,o=ipaca':
> SASL/EXTERNAL authentication started
> ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
> additional info: SASL(-4): no mechanism available:
> 
> - Output providing GSSAPI mechanism:
> $ ldapsearch -Y GSSAPI -s sub -b ou=authorities,ou=ca,o=ipaca
> SASL/GSSAPI authentication started
> ldap_sasl_interactive_bind_s: Local error (-2)
> additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified
> GSS failure.  Minor code may provide more information (Server
> ldap/localh...@example.com not found in Kerberos database)
> 
> - Output providing user credentials:
> $ ldapsearch -D "uid=user1,cn=users,cn=accounts,dc=example,dc=com" -W
> -H ldaps://`hostname` -s sub -b ou=authorities,ou=ca,o=ipaca
> Enter LDAP Password:
> # extended LDIF
> #
> # LDAPv3
> # base

Re: [Freeipa-users] CA not found?

2017-02-09 Thread Guillermo Fuentes 
Hi Fraser,

The cluster was migrated from FreeIPA 3 (CentOS 6) to FreeIPA 4
(CentOS 7) a year ago.

- Output of 'ldapsearch -s sub -b ou=authorities,ou=ca,o=ipaca':
SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
additional info: SASL(-4): no mechanism available:

- Output providing GSSAPI mechanism:
$ ldapsearch -Y GSSAPI -s sub -b ou=authorities,ou=ca,o=ipaca
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified
GSS failure.  Minor code may provide more information (Server
ldap/localh...@example.com not found in Kerberos database)

- Output providing user credentials:
$ ldapsearch -D "uid=user1,cn=users,cn=accounts,dc=example,dc=com" -W
-H ldaps://`hostname` -s sub -b ou=authorities,ou=ca,o=ipaca
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base

Re: [Freeipa-users] pki-tomcat will not start after certificate renewal

2017-02-09 Thread Rob Crittenden 
Joseph Vandermaas wrote:
> All
>   I have been experiencing some issues with a FreeIPA instance that I 
> maintain. More specifically pki-tomcat has not started since around the time 
> it’s certificate renewed. I submitted this bug report 
> https://fedorahosted.org/freeipa/ticket/6521, however a solution has yet to 
> be found.
>   This installation does have one instresting issue that I believe may be 
> causing it to fail. There are two certificates under cn=EXAMPLE.COM IPA 
> CA,cn=certificates,cn=ipa,cn=etc,dc=example,dc=com. Both of these are valid 
> CA certificates and when I run openssl verify with ether of them as the CA 
> and the new subsystem certificate I get an OK message. I also believe that 
> this issue is causing me not to be able to do a ipa-certupdate on the broken 
> IPA server. Is there a way to to clean this up, should I try renewing the CA 
> certificate and get rid of the old LDAP entries?
> 

What did you do, as exactly as you can remember, to get the certificates
renewed?

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

[Freeipa-users] Cross domain or pass through authentication v4.4

2017-02-09 Thread Munoz, Ian A 
Hello,

I can't seem to set up or find decent documentation on either cross-domain or 
pass through authentication. I have tried kerberos cross realm, and saslauthd.

I have two different scenarios I would like to potentially accomplish.

1. FreeIPA domain of a.example.tld pass through authentication to FreeIPA 
domain b.example.tld
2. FreeIPA a.example.tld needs to pass through authentication to our enterprise 
ldap

What is the correct documentation to be following? Should I be trying to 
achieve this via an openldap pass through or a kerberos cross realm trust?

Any thoughts or wisdom would be appreciated.

Thanks,
-Ian Muñoz
Computational Scientist
Oregon State University
-- 
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] pki-tomcat will not start after certificate renewal

2017-02-09 Thread Joseph Vandermaas 
All
I have been experiencing some issues with a FreeIPA instance that I 
maintain. More specifically pki-tomcat has not started since around the time 
it’s certificate renewed. I submitted this bug report 
https://fedorahosted.org/freeipa/ticket/6521, however a solution has yet to be 
found.
This installation does have one instresting issue that I believe may be 
causing it to fail. There are two certificates under cn=EXAMPLE.COM IPA 
CA,cn=certificates,cn=ipa,cn=etc,dc=example,dc=com. Both of these are valid CA 
certificates and when I run openssl verify with ether of them as the CA and the 
new subsystem certificate I get an OK message. I also believe that this issue 
is causing me not to be able to do a ipa-certupdate on the broken IPA server. 
Is there a way to to clean this up, should I try renewing the CA certificate 
and get rid of the old LDAP entries?

-- 
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 not found?

2017-02-09 Thread Fraser Tweedale 
On Thu, Feb 09, 2017 at 09:29:14AM -0500, Guillermo Fuentes wrote:
> Hi list,
> 
> I'm trying to sign a service certificate but it's failing with "CA not found".
> The CA does exist but for some reason the ipa cert-request can't find it:
> $ ipa ca-show ipa
>  Name: ipa
>  Description: IPA CA
>  Authority ID: 0cb513ea-6084-4144-a61c-7a0a8368d25c
>  Subject DN: CN=Certificate Authority,O=EXAMPLE.COM
>  Issuer DN: CN=Certificate Authority,O=EXAMPLE.COM
> 
> This was working in previous versions of freeipa but in our current
> environment isn't working:
> Cluster of four FreeIPA servers
> CentOS Linux release 7.3.1611 (Core)
> ipa-client-common-4.4.0-14.el7.centos.4.noarch
> ipa-client-4.4.0-14.el7.centos.4.x86_64
> ipa-debuginfo-4.2.0-15.0.1.el7_2.6.1.x86_64
> ipa-server-trust-ad-4.4.0-14.el7.centos.4.x86_64
> ipa-server-4.4.0-14.el7.centos.4.x86_64
> ipa-admintools-4.4.0-14.el7.centos.4.noarch
> ipa-server-common-4.4.0-14.el7.centos.4.noarch
> ipa-common-4.4.0-14.el7.centos.4.noarch
> ipa-server-dns-4.4.0-14.el7.centos.4.noarch
> ipa-python-compat-4.4.0-14.el7.centos.4.noarch
> 389-ds-base-1.3.5.10-15.el7_3.x86_64
> 389-ds-base-libs-1.3.5.10-15.el7_3.x86_64
> 389-ds-base-snmp-1.3.5.10-15.el7_3.x86_64
> 389-ds-base-debuginfo-1.3.4.0-30.el7_2.x86_64
> pki-base-java-10.3.3-16.el7_3.noarch
> pki-base-10.3.3-16.el7_3.noarch
> pki-server-10.3.3-16.el7_3.noarch
> pki-ca-10.3.3-16.el7_3.noarch
> pki-symkey-10.3.3-16.el7_3.x86_64
> pki-kra-10.3.3-16.el7_3.noarch
> pki-tools-10.3.3-16.el7_3.x86_64
> krb5-libs-1.14.1-27.el7_3.x86_64
> python-krbV-1.0.90-8.el7.x86_64
> pam_krb5-2.4.8-6.el7.x86_64
> krb5-workstation-1.14.1-27.el7_3.x86_64
> krb5-pkinit-1.14.1-27.el7_3.x86_64
> sssd-krb5-common-1.14.0-43.el7_3.11.x86_64
> krb5-server-1.14.1-27.el7_3.x86_64
> sssd-krb5-1.14.0-43.el7_3.11.x86_64
> 
> ***
> This is the error (same result in all four servers):
> $ ipa cert-request --principal=HTTP/host1.example.com host1.example.com.csr
> ipa: ERROR: Certificate operation cannot be completed: FAILURE (CA not
> found: 0cb513ea-6084-4144-a61c-7a0a8368d25c)
> 
> ***
> >From /var/log/pki/pki-tomcat/ca/debug:
> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
> CMSServlet:service() uri = /ca/eeca/ca/profileSubmitSSLClient
> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
> CMSServlet::service() param name='xml' value='true'
> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
> CMSServlet::service() param name='profileId' value='caIPAserviceCert'
> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
> CMSServlet::service() param name='authorityId'
> value='0cb513ea-6084-4144-a61c-7a0a8368d25c'
> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
> CMSServlet::service() param name='cert_request' value='(sensitive)'
> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
> CMSServlet::service() param name='cert_request_type' value='pkcs10'
> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: CMSServlet:
> caProfileSubmitSSLClient start to service.
> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: xmlOutput true
> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
> ProfileSubmitServlet: isRenewal false
> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: according to
> ccMode, authorization for servlet: caProfileSubmit is LDAP based, not
> XML {1}, use default authz mgr: {2}.
> [07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
> ProfileSubmitServlet: profile: caIPAserviceCert
> CA not found: 0cb513ea-6084-4144-a61c-7a0a8368d25c
> at 
> com.netscape.cms.servlet.profile.ProfileSubmitServlet.processEnrollment(ProfileSubmitServlet.java:239)
> at 
> com.netscape.cms.servlet.profile.ProfileSubmitServlet.process(ProfileSubmitServlet.java:128)
> at 
> com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:515)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
> at sun.reflect.GeneratedMethodAccessor72.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288)
> at 
> org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAsPrivileged(Subject.java:549)
> at 
> org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320)
> at 
> org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:175)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:297)
> at 
> org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
> at 
> org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191)
>

Re: [Freeipa-users] Looking for instructions on one way subtree sync IPA->IPA

2017-02-09 Thread Piper, Nick 
Alexander Bokovoy wrote:

>Unfortunately, we are still far away from making IPA-IPA trust a
>reality. We need to implement several features until we get to the point
>that practical IPA-IPA trust is possible.

Ok, thank you for clarifying - we'll consider how to work around - potentially 
replacing one of the IPA instances with AD for now.

Regards,

 Nick

-- 
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] CA not found?

2017-02-09 Thread Guillermo Fuentes 
Hi list,

I'm trying to sign a service certificate but it's failing with "CA not found".
The CA does exist but for some reason the ipa cert-request can't find it:
$ ipa ca-show ipa
 Name: ipa
 Description: IPA CA
 Authority ID: 0cb513ea-6084-4144-a61c-7a0a8368d25c
 Subject DN: CN=Certificate Authority,O=EXAMPLE.COM
 Issuer DN: CN=Certificate Authority,O=EXAMPLE.COM

This was working in previous versions of freeipa but in our current
environment isn't working:
Cluster of four FreeIPA servers
CentOS Linux release 7.3.1611 (Core)
ipa-client-common-4.4.0-14.el7.centos.4.noarch
ipa-client-4.4.0-14.el7.centos.4.x86_64
ipa-debuginfo-4.2.0-15.0.1.el7_2.6.1.x86_64
ipa-server-trust-ad-4.4.0-14.el7.centos.4.x86_64
ipa-server-4.4.0-14.el7.centos.4.x86_64
ipa-admintools-4.4.0-14.el7.centos.4.noarch
ipa-server-common-4.4.0-14.el7.centos.4.noarch
ipa-common-4.4.0-14.el7.centos.4.noarch
ipa-server-dns-4.4.0-14.el7.centos.4.noarch
ipa-python-compat-4.4.0-14.el7.centos.4.noarch
389-ds-base-1.3.5.10-15.el7_3.x86_64
389-ds-base-libs-1.3.5.10-15.el7_3.x86_64
389-ds-base-snmp-1.3.5.10-15.el7_3.x86_64
389-ds-base-debuginfo-1.3.4.0-30.el7_2.x86_64
pki-base-java-10.3.3-16.el7_3.noarch
pki-base-10.3.3-16.el7_3.noarch
pki-server-10.3.3-16.el7_3.noarch
pki-ca-10.3.3-16.el7_3.noarch
pki-symkey-10.3.3-16.el7_3.x86_64
pki-kra-10.3.3-16.el7_3.noarch
pki-tools-10.3.3-16.el7_3.x86_64
krb5-libs-1.14.1-27.el7_3.x86_64
python-krbV-1.0.90-8.el7.x86_64
pam_krb5-2.4.8-6.el7.x86_64
krb5-workstation-1.14.1-27.el7_3.x86_64
krb5-pkinit-1.14.1-27.el7_3.x86_64
sssd-krb5-common-1.14.0-43.el7_3.11.x86_64
krb5-server-1.14.1-27.el7_3.x86_64
sssd-krb5-1.14.0-43.el7_3.11.x86_64

***
This is the error (same result in all four servers):
$ ipa cert-request --principal=HTTP/host1.example.com host1.example.com.csr
ipa: ERROR: Certificate operation cannot be completed: FAILURE (CA not
found: 0cb513ea-6084-4144-a61c-7a0a8368d25c)

***
>From /var/log/pki/pki-tomcat/ca/debug:
[07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
CMSServlet:service() uri = /ca/eeca/ca/profileSubmitSSLClient
[07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
CMSServlet::service() param name='xml' value='true'
[07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
CMSServlet::service() param name='profileId' value='caIPAserviceCert'
[07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
CMSServlet::service() param name='authorityId'
value='0cb513ea-6084-4144-a61c-7a0a8368d25c'
[07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
CMSServlet::service() param name='cert_request' value='(sensitive)'
[07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
CMSServlet::service() param name='cert_request_type' value='pkcs10'
[07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: CMSServlet:
caProfileSubmitSSLClient start to service.
[07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: xmlOutput true
[07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
ProfileSubmitServlet: isRenewal false
[07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]: according to
ccMode, authorization for servlet: caProfileSubmit is LDAP based, not
XML {1}, use default authz mgr: {2}.
[07/Feb/2017:23:45:49][ajp-bio-127.0.0.1-8009-exec-86]:
ProfileSubmitServlet: profile: caIPAserviceCert
CA not found: 0cb513ea-6084-4144-a61c-7a0a8368d25c
at 
com.netscape.cms.servlet.profile.ProfileSubmitServlet.processEnrollment(ProfileSubmitServlet.java:239)
at 
com.netscape.cms.servlet.profile.ProfileSubmitServlet.process(ProfileSubmitServlet.java:128)
at com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:515)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
at sun.reflect.GeneratedMethodAccessor72.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288)
at 
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:549)
at 
org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320)
at 
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:175)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:297)
at 
org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
at 
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191)
at 
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186)

Re: [Freeipa-users] Looking for instructions on one way subtree sync IPA->IPA

2017-02-09 Thread Alexander Bokovoy 

On to, 09 helmi 2017, Piper, Nick wrote:

Hi Alexander,

Alexander Bokovoy wrote:

On to, 09 helmi 2017, Piper, Nick wrote:



We're currently using FreeIPA 4.2.0, and we have two unrelated
instances of IdM server. We'd like the user list which IPA maintains
in one, to be a superset of the other; so we're looking for one way
replication (of cn=users,cn=accounts,dc=realm, not necessarily of host
entries etc.)



We use a different 'dc' in each instance, and could use a different cn
too if needed.



In short, there is no support for IPA-IPA trust or replication. There
are many reasons for that, including some complex technical issues on
how this could be reliably working.



If you are after actual POSIX systems where users need to logon to use
their services, you may try to configure SSSD with two different domains
(for IPA1 and IPA2). You can look at discussion we had in 2014:
https://www.redhat.com/archives/freeipa-users/2014-January/msg00075.html
You are not necessarily need to enroll the machine in two different
realms, any Kerberos principal would do instead of a host principal to
authenticate against IPA LDAP (see sssd-ldap man page for details on
ldap_sasl_authid).


Thanks, so the idea here would be for SSSD (and any other software
which uses krb or LDAP) to be configured to use both our IPA instances
simultaneously. I'll ponder on this and check into if each of our
applications has support for multiple LDAP servers.


We believe we need one way sync (including passwords) to be able to
authenticate users which are mastered in the 'remote' IPA, even when
the 'remote' IPA is offline. Another option we might explore is
'cross-forest trust', although I believe this would make
authentication unavailable if the 'master' IPA is unavailable. Both
are discussed at
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#summary-indirect
, but again in the context of AD/IPA rather than IPA/IPA.



I'd welcome any pointers on trust or one-way replication between two
IPA instances!



You are stuck, there is no such support between different IPA
deployments.



It would help to actually explain your real use case. So far you
outlined above your approaches to solve a problem which is not really
stated upfront.


Thanks - I'll try to explain the wider picture:

We have a Hadoop deployment which uses an instance of FreeIPA both for
the Operating Systems (using SSSD) and applications which use LDAP
(for authentication, authorisation and for directory search.) This
FreeIPA (Project IPA) is intended to be authoritative for user
accounts which are specific to the project, such as administrators,
contractors, and so on. The project fits into a wider estate, which
uses FreeIPA (call this Enterprise IPA) to manage general user
accounts.

For auditing and consistency purposes, the general users managed in
Enterprise IPA should be able to run POSIX processes under their
username (in this case YARN containers), log into project tools (which
use LDAP to Project IPA - although this could be changed to
SAML/Shibboleth which might avoid Project IPA having to validate
credentials) and so on.


+--+
|  |
| ++   |
| ||   |
| | +---+ +-+ ++  +--+ |   |
| | | IPA   | |Linux OS | |Linux OS|  | App using| |   |
| | |   | | | ||  | LDAP | |   |
| | +---+ +-+ ++  +--+ |   |
| ||   |
| |^   |   |
| |Project +
| ++   |  user1 can own
|  |  processes here
|  |
|  |
|  |
|  |
|   +++-+  +-+ ++  |
|   ||| |  | | ||  |
|   | IPA|| Linux   |  | Linux   | | App using  |  |
|   ||| OS  |  | OS  | | LDAP   |  |
|   +++-+  +-+ ++  |
|  |
|^ |
|| |
| Wider Enterprise Estate  |
+|-+
|
|
 user1 details mastered here


If 'Enterprise' IPA was instead Active Directory, I believe the

Re: [Freeipa-users] Looking for instructions on one way subtree sync IPA->IPA

2017-02-09 Thread Piper, Nick 
Hi Alexander,

Alexander Bokovoy wrote:
>On to, 09 helmi 2017, Piper, Nick wrote:

>>We're currently using FreeIPA 4.2.0, and we have two unrelated
>>instances of IdM server. We'd like the user list which IPA maintains
>>in one, to be a superset of the other; so we're looking for one way
>>replication (of cn=users,cn=accounts,dc=realm, not necessarily of host
>>entries etc.)

>>We use a different 'dc' in each instance, and could use a different cn
>>too if needed.

>In short, there is no support for IPA-IPA trust or replication. There
>are many reasons for that, including some complex technical issues on
>how this could be reliably working.

>If you are after actual POSIX systems where users need to logon to use
>their services, you may try to configure SSSD with two different domains
>(for IPA1 and IPA2). You can look at discussion we had in 2014:
>https://www.redhat.com/archives/freeipa-users/2014-January/msg00075.html
>You are not necessarily need to enroll the machine in two different
>realms, any Kerberos principal would do instead of a host principal to
>authenticate against IPA LDAP (see sssd-ldap man page for details on
>ldap_sasl_authid).

Thanks, so the idea here would be for SSSD (and any other software
which uses krb or LDAP) to be configured to use both our IPA instances
simultaneously. I'll ponder on this and check into if each of our
applications has support for multiple LDAP servers.

>>We believe we need one way sync (including passwords) to be able to
>>authenticate users which are mastered in the 'remote' IPA, even when
>>the 'remote' IPA is offline. Another option we might explore is
>>'cross-forest trust', although I believe this would make
>>authentication unavailable if the 'master' IPA is unavailable. Both
>>are discussed at
>>https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#summary-indirect
>>, but again in the context of AD/IPA rather than IPA/IPA.

>>I'd welcome any pointers on trust or one-way replication between two
>>IPA instances!

>You are stuck, there is no such support between different IPA
>deployments.

>It would help to actually explain your real use case. So far you
>outlined above your approaches to solve a problem which is not really
>stated upfront.

Thanks - I'll try to explain the wider picture:

We have a Hadoop deployment which uses an instance of FreeIPA both for
the Operating Systems (using SSSD) and applications which use LDAP
(for authentication, authorisation and for directory search.) This
FreeIPA (Project IPA) is intended to be authoritative for user
accounts which are specific to the project, such as administrators,
contractors, and so on. The project fits into a wider estate, which
uses FreeIPA (call this Enterprise IPA) to manage general user
accounts.

For auditing and consistency purposes, the general users managed in
Enterprise IPA should be able to run POSIX processes under their
username (in this case YARN containers), log into project tools (which
use LDAP to Project IPA - although this could be changed to
SAML/Shibboleth which might avoid Project IPA having to validate
credentials) and so on.


+--+
 
|  |
 
| ++   |
 
| ||   |
 
| | +---+ +-+ ++  +--+ |   |
 
| | | IPA   | |Linux OS | |Linux OS|  | App using| |   |
 
| | |   | | | ||  | LDAP | |   |
 
| | +---+ +-+ ++  +--+ |   |
 
| ||   |
 
| |^   |   |
 
| |Project +
 
| ++   |  user1 can own 
 
|  |  processes here
 
|  |
 
|  |
 
|  |
 
|  |
 
|   +++-+  +-+ ++  |
 
|   ||| |  | | ||  |
 
|   |

Re: [Freeipa-users] Looking for instructions on one way subtree sync IPA->IPA

2017-02-09 Thread Alexander Bokovoy 

On to, 09 helmi 2017, Piper, Nick wrote:

Hi FreeIPA-users,

We're currently using FreeIPA 4.2.0, and we have two unrelated
instances of IdM server. We'd like the user list which IPA maintains
in one, to be a superset of the other; so we're looking for one way
replication (of cn=users,cn=accounts,dc=realm, not necessarily of host
entries etc.)

We use a different 'dc' in each instance, and could use a different cn
too if needed.


In short, there is no support for IPA-IPA trust or replication. There
are many reasons for that, including some complex technical issues on
how this could be reliably working.

If you are after actual POSIX systems where users need to logon to use
their services, you may try to configure SSSD with two different domains
(for IPA1 and IPA2). You can look at discussion we had in 2014:
https://www.redhat.com/archives/freeipa-users/2014-January/msg00075.html
You are not necessarily need to enroll the machine in two different
realms, any Kerberos principal would do instead of a host principal to
authenticate against IPA LDAP (see sssd-ldap man page for details on
ldap_sasl_authid).




So far we've found instructions on full mutual replication:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ipa-replica-manage.html

This one is for generic 389-ds replication of IPA flat DIT.


and a one way sync from Active Directory:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/managing-sync-agmt.html#changing-subtree

This one is for synchronizing with the help of a special daemon running
on Windows Server side.



but not one way sync from IPA.

I'm hoping that we can do this between two IPA instances, probably
still using ipa-replica-manage, although oneWaySync only has options
'fromWindows' and 'toWindows' according to
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/managing-sync-agmt.html#changing-subtree
. Is there anything actually ActiveDirectory specific about this?

Yes, it depends on specific windows program that is running on Windows
domain controllers and plugs into their infrastructure of user
information updates.


We believe we need one way sync (including passwords) to be able to
authenticate users which are mastered in the 'remote' IPA, even when
the 'remote' IPA is offline. Another option we might explore is
'cross-forest trust', although I believe this would make
authentication unavailable if the 'master' IPA is unavailable. Both
are discussed at
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#summary-indirect
, but again in the context of AD/IPA rather than IPA/IPA.

I'd welcome any pointers on trust or one-way replication between two
IPA instances!

You are stuck, there is no such support between different IPA
deployments.

It would help to actually explain your real use case. So far you
outlined above your approaches to solve a problem which is not really
stated upfront.
--
/ 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

[Freeipa-users] Looking for instructions on one way subtree sync IPA->IPA

2017-02-09 Thread Piper, Nick 
Hi FreeIPA-users,

We're currently using FreeIPA 4.2.0, and we have two unrelated
instances of IdM server. We'd like the user list which IPA maintains
in one, to be a superset of the other; so we're looking for one way
replication (of cn=users,cn=accounts,dc=realm, not necessarily of host
entries etc.)

We use a different 'dc' in each instance, and could use a different cn
too if needed.

So far we've found instructions on full mutual replication:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ipa-replica-manage.html

and a one way sync from Active Directory:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/managing-sync-agmt.html#changing-subtree

but not one way sync from IPA.

I'm hoping that we can do this between two IPA instances, probably
still using ipa-replica-manage, although oneWaySync only has options
'fromWindows' and 'toWindows' according to 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/managing-sync-agmt.html#changing-subtree
 . Is there anything actually ActiveDirectory specific about this?

We believe we need one way sync (including passwords) to be able to
authenticate users which are mastered in the 'remote' IPA, even when
the 'remote' IPA is offline. Another option we might explore is
'cross-forest trust', although I believe this would make
authentication unavailable if the 'master' IPA is unavailable. Both
are discussed at
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#summary-indirect
, but again in the context of AD/IPA rather than IPA/IPA.

I'd welcome any pointers on trust or one-way replication between two
IPA instances!

Many thanks,

 Nick

-- 
CGI IT UK Limited. A CGI Group Inc. Company
Registered Office 250 Brook Drive, Green Park, Reading RG2 6UA, United Kingdom. 
Registered in England & Wales - Number 947968




-- 
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, AXFR and DS records

2017-02-09 Thread Ben Roberts 
Hi Tomas,

> when I add a DS record to LDAP (without any DNSSEC configuration),
> it is included in my AXFR transfer. I'm using bind-dyndb-ldap-10.1.
>
> I suppose you have DNSSEC configured. Could you be affected by the
> limitations mentioned in [1]?

Yes, dnssec is otherwise fully configured (the only bit I don't yet
have is the DS records for the "example.local" parent domain
registered upstream, but that shouldn't have any impact here. I don't
think the linked limitations apply, I'm not attempting to use the CDS
or CDNSKEY record types, and am manually specifying the DS records for
the child zone.

This is with bind 9.11 and bind-dyndb-ldap 11.0.

Regards,
Ben Roberts

-- 
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] sudo rules are not active immediatly

2017-02-09 Thread Pavel Březina 

On 02/08/2017 04:03 PM, Nathanaël Blanchet wrote:



Le 08/02/2017 à 13:00, Pavel Březina a écrit :

On 02/08/2017 11:59 AM, Nathanaël Blanchet wrote:

Hello,
on latest IPA, when adding a command to a rule or a sudo option for
example, the change is not active on the user session.
For example, after removing !authenticate option, I still can execute
sudo commands without password.
I tried to logout and relogin, but nothing changes, but on a new vm
where never logeed in before it wroks.
Is there a cache or somting to do so as to commands to be immediatly
available?



Hi,
sudo rules are cache on the client and refresh happens periodically.
We have several update mechanisms that deals with finding new rules,
deleting non-existent ones and updating expired but it cannot be
performed on desired at the moment. We have a ticket for that [1].
Please see 'man sssd-sudo' to get better understanding how it works.


it's said that sssd-sudo has been created to be near of the local
sudoers functionnment. So I suppose the three described mechanisms are
intended to converge to a near realtime rule change.
It's true that waiting for an undefinied time, rules become available...
but is there an estimated time of availibility? Is it rather 15min or
one hour (I suppose beyond is not usable)

It is possible to expired cached rules with sss_cache. This won't find
you newly added rules but it will fetch updated rules and removed
deleted ones.

[1] https://fedorahosted.org/sssd/ticket/2884


Depending on how often does your environment change, you can adjust sudo 
rules updates with following options:


- entry_cache_sudo_timeout -- how long is the cache ruled valid, when 
the timeout is exceeded the rule is updated from ldap


- ldap_sudo_smart_refresh_interval -- periodical update that fetches 
newly added or modified rules from the last lookup (uses 
modifyTimestamp/entryUSN operational attribute to do so)


- ldap_sudo_full_refresh_interval -- periodical update that simply 
deletes current cached rules and downloads those stored in ldap


--
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, AXFR and DS records

2017-02-09 Thread Tomas Krizek 
On 02/08/2017 11:59 PM, Ben Roberts wrote:
> Hi all,
>
> This is a question more about bind-dyndb-ldap rather than freeipa, but
> I understand it's written/maintained by the freeipa project and so
> this might be the most appropriate place to ask. I have setup
> bind-dyndb-ldap to read some zones from openldap, with multiple
> nameservers acting as masters and one nameserver running as a slave
> via the usual notify/transfer mechanism. I'm not seeing any DS records
> transfer across to the slave nameserver, nor when I manually query the
> primaries with an AFXR request. This includes both the apex DS
> records, automatically generated by bind-dyndb-ldap, but more
> importantly the glue dSRecord objects for a delegated subdomain.
>
> I note that the dSRecord entries are present in
> /var/named/dyndb-ldap/$view/master/$zone/raw but not present in
> /var/named/dyndb-ldap/$view/master/$zone/signed.
>
> Example (domain name and ip addresses obfuscated, but all other fields
> are unmodified):
> $ dig +noall +answer DS subdomain.example.local @127.0.01
> subdomain.example.local.   600 IN  DS  38589 7 1
> 6C410EF5A47631FBA2C3BC295A90363EA86A1846
> subdomain.example.local.   600 IN  DS  38589 7 2
> 23E22A49BBF2AD0E3F4668CB4C0DB52EE60ACA4308C1DE002A47AD7B 99734334
>
> $ dig +noall +answer AXFR subdomain.example.local @127.0.0.1
> | head -n 1
> subdomain.example.local.   600 IN  SOA ns1.example.local.
> hostmaster.example.local. 2016050416 43200 3600 1209600 3600
>
> $ dig +noall +answer AXFR subdomain.example.local @127.0.0.1
> | grep '\bDS\b'
> $
>
> This behaviour doesn't seem right to me. I would expect the DS records
> to be transferred to the slaves as normal so that any glue records are
> correctly present on all nameservers. I can't see any references in
> the bind-dyndb-ldap wiki/readme or code comments that would explain DS
> records being treated specially, but please do correct me if I'm wrong.
>
> Regards,
> Ben Roberts
>
>
Hi,

when I add a DS record to LDAP (without any DNSSEC configuration), it is
included in my AXFR transfer. I'm using bind-dyndb-ldap-10.1.

I suppose you have DNSSEC configured. Could you be affected by the
limitations mentioned in [1]?

[1] -
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/OpenDNSSEC2BINDKeyStates#Limitationsmissingfeatures

-- 
Tomas Krizek



signature.asc
Description: OpenPGP digital signature
-- 
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