Re: [Freeipa-users] Configuring freeipa 4.4 as a subCA to in-house rootCA : ERROR IPA CA certificate not found in

2017-03-27 Thread Fraser Tweedale 
Hi Clark,

On Mon, Mar 27, 2017 at 04:19:42PM +, System Administration Team wrote:
> Fraser,
> 
> I cannot pass the DN or CN as part of the subject on the command line 
> ipa-server-install 
> 
> Ipa-server-install appears to set the CN to 'Certificate Authority' from the 
> openssl output.
>
The ability to control this was added in v4.5:
http://www.freeipa.org/page/Releases/4.5.0#Fully_customisable_CA_name

But, the Subject DN in the CSR is advisory; we have no control over
what the external CA actually does.  FreeIPA requires the signed
cert to match what was in the CSR.

> I believe the preferred for a subCA should be the FQDN of the subCA server 
> which is the ipa install.
> 
It doesn't matter, as long as it's different from other CAs.

> The final error when I try to run ipa-server-install:
> 
> ipa.ipapython.install.cli.install_tool(Server): ERRORIPA CA certificate 
> not found in /etc/pki/tls/certs/ipa.cert.pem, /etc/pki/tls/certs/ca.cert.pem
> ipa.ipapython.install.cli.install_tool(Server): ERRORThe 
> ipa-server-install command failed. See /var/log/ipaserver-install.log for 
> more information
> 
This is consistent with the signed cert having a different Subject
DN from what IPA expects (which is what it put into the CSR).

Cheers,
Fraser

> Thank You
> 
> Clark
> 
> > 
> > 
> Does the subject distinguished name in the signed certificate exactly match 
> what was in the CSR?
> 
> 
> 2017-03-27 IPA Install
> 
> [root@ipa certs]# ipa-server-install --external-ca --domain=camgian.com 
> --hostname=ipa.camgian.com --realm=CAMGIAN.COM --subject 'OU=IT,O=Camgian 
> Microsystems,L=Starkville,ST=Mississippi,C=US,mail='
> 
> The log file for this installation can be found in 
> /var/log/ipaserver-install.log 
> ==
> This program will set up the IPA Server.
> 
> This includes:
>   * Configure a stand-alone CA (dogtag) for certificate management
>   * Configure the Network Time Daemon (ntpd)
>   * Create and configure an instance of Directory Server
>   * Create and configure a Kerberos Key Distribution Center (KDC)
>   * Configure Apache (httpd)
> 
> To accept the default shown in brackets, press the Enter key.
> 
> Do you want to configure integrated DNS (BIND)? [no]:
> 
> Certain directory server operations require an administrative user.
> This user is referred to as the Directory Manager and has full access to the 
> Directory for system management tasks and will be added to the instance of 
> directory server created for IPA.
> The password must be at least 8 characters long.
> 
> Directory Manager password:
> Password (confirm):
> 
> The IPA server requires an administrative user, named 'admin'.
> This user is a regular system account used for IPA server administration.
> 
> IPA admin password:
> Password (confirm):
> 
> 
> The IPA Master Server will be configured with:
> Hostname:   ipa.camgian.com
> IP address(es): 192.168.200.3
> Domain name:camgian.com
> Realm name: CAMGIAN.COM
> 
> Continue to configure the system with these values? [no]: yes
> 
> The following operations may take some minutes to complete.
> Please wait until the prompt is returned.
> 
> 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/47]: creating directory server user
>   [2/47]: creating directory server instance
>   [3/47]: updating configuration in dse.ldif
>   [4/47]: restarting directory server
>   [5/47]: adding default schema
>   [6/47]: enabling memberof plugin
>   [7/47]: enabling winsync plugin
>   [8/47]: configuring replication version plugin
>   [9/47]: enabling IPA enrollment plugin
>   [10/47]: enabling ldapi
>   [11/47]: configuring uniqueness plugin
>   [12/47]: configuring uuid plugin
>   [13/47]: configuring modrdn plugin
>   [14/47]: configuring DNS plugin
>   [15/47]: enabling entryUSN plugin
>   [16/47]: configuring lockout plugin
>   [17/47]: configuring topology plugin
>   [18/47]: creating indices
>   [19/47]: enabling referential integrity plugin
>   [20/47]: configuring certmap.conf
>   [21/47]: configure autobind for root
>   [22/47]: configure new location for managed entries
>   [23/47]: configure dirsrv ccache
>   [24/47]: enabling SASL mapping fallback
>   [25/47]: restarting directory server
>   [26/47]: adding sasl mappings to the directory
>   [27/47]: adding default layout
>   [28/47]: adding delegation layout
>   [29/47]: creating container for managed entries
>   [30/47]: configuring user private groups
>   [31/47]: configuring netgroups from hostgroups
>   [32/47]: creating default Sudo bind user
>   [33/47]: creating default Auto Member layout
>   [34/47]: adding range check plugin
>   [35/47]: creating default HBAC rule allow_all
>   [36/47]: adding sasl mappings to the

Re: [Freeipa-users] Sudo Rule flag limitations

2017-03-27 Thread Sean Hogan 

Disregard .. I figured it out

just added /usr/bin fdisk -l to command list
run as user root and applied the command to sudo rule

Running as expected where sudo fdisk /dev/sda fails but sudo fdisk -l works





Sean Hogan





From:   Sean Hogan/Durham/IBM@IBMUS
To: freeipa-users 
Date:   03/27/2017 01:55 PM
Subject:[Freeipa-users] Sudo Rule flag limitations
Sent by:freeipa-users-boun...@redhat.com



Hello,

I was wondering how possible it would be to allow sudo commands with
certain flags but not the actual command

Case in point:

If a user requests sudo fdisk -l to view partitions can this be set without
giving access to sudo fdisk /dev/sda ?

Would the sudo rule have to deny fdisk /dev/sda but allow fdisk -l? Not
really sure how that would work.


 
 ipa-client-3.0.0-50.el6.1.x86_64
 ipa-server-selinux-3.0.0-50.el6.1.x86_64
 ipa-server-3.0.0-50.el6.1.x86_64
 sssd-ipa-1.13.3-22.el6_8.4.x86_64   
 python-libipa_hbac-1.13.3-22.el6_8.4.x86_64 
 ipa-admintools-3.0.0-50.el6.1.x86_64
 python-iniparse-0.3.1-2.1.el6.noarch
 









Thank you



Sean Hogan




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

-- 
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] Sudo Rule flag limitations

2017-03-27 Thread Sean Hogan 

Hello,

  I was wondering how possible it would be to allow sudo commands with
certain flags but not the actual command

Case in point:

  If a user requests sudo fdisk -l to view partitions can this be set
without giving access to sudo fdisk /dev/sda ?

Would the sudo rule have to deny fdisk /dev/sda but allow fdisk -l?  Not
really sure how that would work.


 
 ipa-client-3.0.0-50.el6.1.x86_64
 ipa-server-selinux-3.0.0-50.el6.1.x86_64
 ipa-server-3.0.0-50.el6.1.x86_64
 sssd-ipa-1.13.3-22.el6_8.4.x86_64   
 python-libipa_hbac-1.13.3-22.el6_8.4.x86_64 
 ipa-admintools-3.0.0-50.el6.1.x86_64
 python-iniparse-0.3.1-2.1.el6.noarch
 








Thank you



Sean Hogan




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

Re: [Freeipa-users] SSSD dyndns_update on machine with multiple IP address

2017-03-27 Thread Jakub Hrozek 
On Mon, Mar 27, 2017 at 06:34:24PM +0200, David Goudet wrote:
> Hi,
> 
> Thanks to dyndns_update=True parameter, SSSD service on client machine 
> updating host DNS entry in FreeIPA.
> Everything is fine on machines which have only one IP adress on network 
> interface.
> I have problem with machines which have more that one IP address on network 
> interface: if machine have two IP address, SSSD update host DNS entry with 
> these two IP address.
> 
> To reproduce the problem:
> Host have -IP1- and i add -IP2-
> ip addr add -IP2-/26 dev em1
> 
> ip addr list:
> em1:  mtu 1496 qdisc mq state UP qlen 1000
> link/ether 
> inet -IP1-/26 brd  scope global em1
> inet -IP2-/26 scope global secondary em1
>valid_lft forever preferred_lft forever
> 
> DNS resolution (dig) before restarting sssd returns only -IP1-. After 
> restarting sssd returns -IP1- & -IP2-
> 
> In dyndns_update manpage, we have "The IP address of the IPA LDAP connection 
> is used for the updates", what does it means? Is it IP address of the DNS 
> server (used to update the DNS entry)? or is it IP address on client machine 
> used during LDAP TCP bind (-IP1- in my case)?
> 
> dyndns_update (boolean)
>Optional. This option tells SSSD to automatically update the DNS 
> server built into FreeIPA v2 with the IP address of this client.
>The update is secured using GSS-TSIG. The IP address of the IPA 
> LDAP connection is used for the updates, if it is not otherwise
>specified by using the “dyndns_iface” option.
> 
> Is it normal behaviour that SSSD add in host DNS entry every IPs enabled on 
> client machine?

Looks like this was a deliberate change:
https://pagure.io/SSSD/sssd/issue/2558
but to be honest, I forgot why exactly we did this. Martin, do you know?

> Is it possible to configure SSSD to update DNS with only IP address "primary" 
> in ip addr list or which is used to FreeIPA server communication (-IP1- used 
> on TCP binding)?

Only if the IP addresses are of different families (v4/v6), then it's
possible to restrict one of the families.

-- 
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] Configuring freeipa 4.4 as a subCA to in-house rootCA : ERROR IPA CA certificate not found in

2017-03-27 Thread Tomas Krizek 
On 03/27/2017 06:19 PM, System Administration Team wrote:
> [root@ipa certs]# openssl req -in /root/ipa.csr -noout -text
> Certificate Request:
> Data:
> Version: 0 (0x0)
> Subject: mail=, C=US, ST=Mississippi, L=Starkville, 
> O=Camgian Microsystems, OU=IT, CN=Certificate Authority
> Subject Public Key Info:
> Public Key Algorithm: rsaEncryption
> Public-Key: (2048 bit)
> Modulus:
> 
> Exponent: 65537 (0x10001)
> Attributes:
> Requested Extensions:
> X509v3 Basic Constraints: critical
> CA:TRUE
> X509v3 Key Usage: critical
> Digital Signature, Non Repudiation, Certificate Sign, CRL Sign
> Signature Algorithm: sha256WithRSAEncryption
>  
> [root@ipa certs]#
>
> Sign ipa.csr
>
> root@rootCA:~/ca# openssl ca -config openssl.cnf -policy policy_loose 
> -extensions v3_intermediate_ca -days 3650 -notext -md sha256 -in 
> /home/camgian/ipa.csr -out intermediate/certs/ipa.cert.pem Using 
> configuration from openssl.cnf Enter pass phrase for 
> /root/ca/private/ca.key.pem:
> Check that the request matches the signature Signature ok Certificate Details:
> Serial Number: 4099 (0x1003)
> Validity
> Not Before: Mar 27 15:49:18 2017 GMT
> Not After : Mar 25 15:49:18 2027 GMT
> Subject:
> countryName   = US
> stateOrProvinceName   = Mississippi
> localityName  = Starkville
> organizationName  = Camgian Microsystems
> organizationalUnitName= IT
> commonName= Certificate Authority
The signed certificate's Subject field seems to be missing the
mail=. Perhaps the signing rules do not permit this field?
> [root@ipa certs]# ipa-server-install --domain=camgian.com 
> --hostname=ipa.camgian.com --realm=CAMGIAN.COM --subject 'OU=IT,O=Camgian 
> Microsystems,L=Starkville,ST=Mississippi,C=US,mail=' 
> --external-cert-file=/etc/pki/tls/certs/ipa.cert.pem 
> --external-cert-file=/etc/pki/tls/certs/ca.cert.pem
I believe you can't force IPA to use a different subject at the second
step of setting up external CA. I think it's only used to generate the
CSR in the first step.
> ipa.ipapython.install.cli.install_tool(Server): ERRORIPA CA certificate 
> not found in /etc/pki/tls/certs/ipa.cert.pem, /etc/pki/tls/certs/ca.cert.pem
> ipa.ipapython.install.cli.install_tool(Server): ERRORThe 
> ipa-server-install command failed. See /var/log/ipaserver-install.log for 
> more information
The installation most likely fails because mail= is expected to
be a part of the signed certificate's subject field.

-- 
Tomas Krizek

PGP: 4A8B A48C 2AED 933B D495  C509 A1FB A5F7 EF8C 4869




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

[Freeipa-users] SSSD dyndns_update on machine with multiple IP address

2017-03-27 Thread David Goudet 
Hi,

Thanks to dyndns_update=True parameter, SSSD service on client machine updating 
host DNS entry in FreeIPA.
Everything is fine on machines which have only one IP adress on network 
interface.
I have problem with machines which have more that one IP address on network 
interface: if machine have two IP address, SSSD update host DNS entry with 
these two IP address.

To reproduce the problem:
Host have -IP1- and i add -IP2-
ip addr add -IP2-/26 dev em1

ip addr list:
em1:  mtu 1496 qdisc mq state UP qlen 1000
link/ether 
inet -IP1-/26 brd  scope global em1
inet -IP2-/26 scope global secondary em1
   valid_lft forever preferred_lft forever

DNS resolution (dig) before restarting sssd returns only -IP1-. After 
restarting sssd returns -IP1- & -IP2-

In dyndns_update manpage, we have "The IP address of the IPA LDAP connection is 
used for the updates", what does it means? Is it IP address of the DNS server 
(used to update the DNS entry)? or is it IP address on client machine used 
during LDAP TCP bind (-IP1- in my case)?

dyndns_update (boolean)
   Optional. This option tells SSSD to automatically update the DNS 
server built into FreeIPA v2 with the IP address of this client.
   The update is secured using GSS-TSIG. The IP address of the IPA LDAP 
connection is used for the updates, if it is not otherwise
   specified by using the “dyndns_iface” option.

Is it normal behaviour that SSSD add in host DNS entry every IPs enabled on 
client machine?
Is it possible to configure SSSD to update DNS with only IP address "primary" 
in ip addr list or which is used to FreeIPA server communication (-IP1- used on 
TCP binding)?

My environment is:
Client: Centos 7.2
sssd-common-1.13.0-40.el7_2.12.x86_64
sssd-ipa-1.13.0-40.el7_2.12.x86_64
sssd-1.13.0-40.el7_2.12.x86_64
sssd-client-1.13.0-40.el7_2.12.x86_64
FreeIPA server: Centos 6.7
ipa-server-3.0.0-47.el6.centos.2.x86_64
bind-9.8.2-0.30.rc1.el6_6.3.x86_64
bind-utils-9.8.2-0.37.rc1.el6_7.7.x86_64
bind-libs-9.8.2-0.37.rc1.el6_7.7.x86_64
rpcbind-0.2.0-11.el6_7.x86_64
bind-libs-9.8.2-0.30.rc1.el6_6.3.x86_64
rpcbind-0.2.0-11.el6.x86_64
bind-dyndb-ldap-2.3-8.el6.x86_64
bind-9.8.2-0.37.rc1.el6_7.7.x86_64


SSSD configuration on client:
[domain/]

debug_level=18
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = 
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ldap_tls_cacert = /etc/ipa/ca.crt
chpass_provider = ipa
dyndns_update = True
ipa_server = _srv_, ds01., ds01.
dns_discovery_domain = 


Named FreeIPA logs:
---
Mar 27 17:03:57 ds01. named[6607]: client -IP1-#36331: updating 
zone '/IN': deleting rrset at '' A
Mar 27 17:03:57 ds01. named[6607]: update_record (psearch) failed, 
dn 'idnsName=2,idnsname=.in-addr.arpa.,cn=dns,dc=yyy,dc=xxx' change 
type 0x4. Records can be outdated, run `rndc reload`: not found
Mar 27 17:03:57 ds01. named[6607]: zone /IN: sending 
notifies (serial 1490615011)
Mar 27 17:03:57 ds01. named[6607]: client -IP1-#46187: updating 
zone '/IN': deleting rrset at '.' 
Mar 27 17:03:57 ds01. named[6607]: client -IP1-#54691: updating 
zone '/IN': adding an RR at '.' A
Mar 27 17:03:57 ds01. named[6607]: client -IP1-#54691: updating 
zone '/IN': adding an RR at '.' A
Mar 27 17:03:57 ds01. named[6607]: zone .in-addr.arpa/IN: 
sending notifies (serial 1490627037)
Mar 27 17:04:02 ds01. named[6607]: zone /IN: sending 
notifies (serial 1490627038)

SSSD trace log on client during sssd restart:
---
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [ipa_dyndns_update_send] 
(0x0400): Performing update
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [sdap_id_op_connect_step] 
(0x4000): reusing cached connection
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [sdap_id_op_destroy] (0x4000): 
releasing operation connection
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_is_address] (0x4000): 
[.] does not look like an IP address
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_gethostbyname_step] 
(0x2000): Querying DNS
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] 
[resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 
'.' in DNS
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [schedule_request_timeout] 
(0x2000): Scheduling a timeout of 6 seconds
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [schedule_timeout_watcher] 
(0x2000): Scheduling DNS timeout watcher
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [unschedule_timeout_watcher] 
(0x4000): Unscheduling DNS timeout watcher
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] 
[resolv_gethostbyname_dns_parse] (0x1000): Parsing an A reply
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [request_watch_destructor] 
(0x0400): Deleting request watch
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_is_address] (0x4000): 
[.] does not look like an IP address
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_gethostbyname_step] 
(0x2000): Querying DNS
(Mon Mar 27 17:03:56 2017) [sssd[be[]]]

Re: [Freeipa-users] Configuring freeipa 4.4 as a subCA to in-house rootCA : ERROR IPA CA certificate not found in

2017-03-27 Thread System Administration Team 
Fraser,

I cannot pass the DN or CN as part of the subject on the command line 
ipa-server-install 

Ipa-server-install appears to set the CN to 'Certificate Authority' from the 
openssl output.  I believe the preferred for a subCA should be the FQDN of 
the subCA server which is the ipa install.

The final error when I try to run ipa-server-install:

ipa.ipapython.install.cli.install_tool(Server): ERRORIPA CA certificate not 
found in /etc/pki/tls/certs/ipa.cert.pem, /etc/pki/tls/certs/ca.cert.pem
ipa.ipapython.install.cli.install_tool(Server): ERRORThe ipa-server-install 
command failed. See /var/log/ipaserver-install.log for more information

Thank You

Clark

> 
> 
Does the subject distinguished name in the signed certificate exactly match 
what was in the CSR?


2017-03-27 IPA Install

[root@ipa certs]# ipa-server-install --external-ca --domain=camgian.com 
--hostname=ipa.camgian.com --realm=CAMGIAN.COM --subject 'OU=IT,O=Camgian 
Microsystems,L=Starkville,ST=Mississippi,C=US,mail='

The log file for this installation can be found in 
/var/log/ipaserver-install.log 
==
This program will set up the IPA Server.

This includes:
  * Configure a stand-alone CA (dogtag) for certificate management
  * Configure the Network Time Daemon (ntpd)
  * Create and configure an instance of Directory Server
  * Create and configure a Kerberos Key Distribution Center (KDC)
  * Configure Apache (httpd)

To accept the default shown in brackets, press the Enter key.

Do you want to configure integrated DNS (BIND)? [no]:

Certain directory server operations require an administrative user.
This user is referred to as the Directory Manager and has full access to the 
Directory for system management tasks and will be added to the instance of 
directory server created for IPA.
The password must be at least 8 characters long.

Directory Manager password:
Password (confirm):

The IPA server requires an administrative user, named 'admin'.
This user is a regular system account used for IPA server administration.

IPA admin password:
Password (confirm):


The IPA Master Server will be configured with:
Hostname:   ipa.camgian.com
IP address(es): 192.168.200.3
Domain name:camgian.com
Realm name: CAMGIAN.COM

Continue to configure the system with these values? [no]: yes

The following operations may take some minutes to complete.
Please wait until the prompt is returned.

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/47]: creating directory server user
  [2/47]: creating directory server instance
  [3/47]: updating configuration in dse.ldif
  [4/47]: restarting directory server
  [5/47]: adding default schema
  [6/47]: enabling memberof plugin
  [7/47]: enabling winsync plugin
  [8/47]: configuring replication version plugin
  [9/47]: enabling IPA enrollment plugin
  [10/47]: enabling ldapi
  [11/47]: configuring uniqueness plugin
  [12/47]: configuring uuid plugin
  [13/47]: configuring modrdn plugin
  [14/47]: configuring DNS plugin
  [15/47]: enabling entryUSN plugin
  [16/47]: configuring lockout plugin
  [17/47]: configuring topology plugin
  [18/47]: creating indices
  [19/47]: enabling referential integrity plugin
  [20/47]: configuring certmap.conf
  [21/47]: configure autobind for root
  [22/47]: configure new location for managed entries
  [23/47]: configure dirsrv ccache
  [24/47]: enabling SASL mapping fallback
  [25/47]: restarting directory server
  [26/47]: adding sasl mappings to the directory
  [27/47]: adding default layout
  [28/47]: adding delegation layout
  [29/47]: creating container for managed entries
  [30/47]: configuring user private groups
  [31/47]: configuring netgroups from hostgroups
  [32/47]: creating default Sudo bind user
  [33/47]: creating default Auto Member layout
  [34/47]: adding range check plugin
  [35/47]: creating default HBAC rule allow_all
  [36/47]: adding sasl mappings to the directory
  [37/47]: adding entries for topology management
  [38/47]: initializing group membership
  [39/47]: adding master entry
  [40/47]: initializing domain level
  [41/47]: configuring Posix uid/gid generation
  [42/47]: adding replication acis
  [43/47]: enabling compatibility plugin
  [44/47]: activating sidgen plugin
  [45/47]: activating extdom plugin
  [46/47]: tuning directory server
  [47/47]: configuring directory to start on boot Done configuring directory 
server (dirsrv).
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30 
seconds
  [1/8]: creating certificate server user
  [2/8]: configuring certificate server instance The next step is to get 
/root/ipa.csr signed by your CA and re-run /usr/sbin/ipa-server-install as:
/usr/sbin/ipa-server-install

Re: [Freeipa-users] First-class support for the docker image

2017-03-27 Thread Martin Basti 



On 03/25/2017 12:55 AM, Terence Kent wrote:

Hello,

We've been using the FreeIPA docker image for a few years now with 
great success. I really can't overstate how much we get by using a 
container deployment for FreeIPA. We can now easily test anything from 
version upgrades to orchestration code  against either test data and 
our production data set. That, and we get all the typical docker 
goodness (we can easily move the container between hosts, change the 
underlying OS independently, etc, etc).


That said, lots of the work in the freeipa docker image's gitrepo are 
things that seem like they belong in the freeipa main codebase. We've 
had to trace through the freeipa-container source from time to time to 
diagnose issues and we see situations where the docker build file 
actually modifies python code using text replaces.


This seems both easily breakable and like a lot more work than just 
modifying the source file to optionally support whatever a 
containerized environment needs. Is there a reason to keep container 
support out of the main freeipa project?


Best,
Terence




Hello,

we have plans to update FreeIPA codebase to avoid hacks in Docker, but 
we had more prioritized tasks to do.  However we are looking forward to 
merging community patches to have synchronized FreeIPA code base and 
containerized FreeIPA


It was separated due rapid FreeIPA container development to make it 
possible to work ASAP without waiting for FreeIPA core.


Martin


--
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] Configuring freeipa 4.4 as a subCA to in-house rootCA : ERROR IPA CA certificate not found in

2017-03-27 Thread Fraser Tweedale 
On Fri, Mar 24, 2017 at 03:26:31PM +, System Administration Team wrote:
> >From old threads back in August 2016 I have been able to get closer to 
> >installing freeipa server as a subCA to our in house rootCA
> 
> https://www.redhat.com/archives/freeipa-users/2016-August/msg00269.html
> 
> Running the initial install command
> 
> ipa-server-install --external-ca --domain=camgian.com 
> --hostname=ipasrvr.camgian.com --realm=CAMGIAN.COM --subject 'OU=IT,O=Camgian 
> Microsystems,L=Starkville,ST=Mississippi,C=US'
> 
> I am provided with /root/ipa.csr that I can signed with our rootCA
> 
> But when I run the subsequent command it fails to find the certificate in the 
> chain.
> 
> ipa-server-install --external-ca --domain=camgian.com 
> --hostname=ipasrvr.camgian.com --realm=CAMGIAN.COM --subject 'OU=IT,O=Camgian 
> Microsystems,L=Starkville,ST=Mississippi,C=US' 
> --external-cert-file=/etc/pki/tls/certs/ipasrvr.cert.pem 
> --external-cert-file=/etc/pki/tls/certs/ca.cert.pem
> 
> It fails at:
> 
> ipa.ipapython.install.cli.install_tool(Server): ERRORIPA CA certificate 
> not found in /etc/pki/tls/certs/ipasrvr.cert.pem, 
> /etc/pki/tls/certs/ca.cert.pem
> ipa.ipapython.install.cli.install_tool(Server): ERRORThe 
> ipa-server-install command failed. See /var/log/ipaserver-install.log for 
> more information
> 
> Any help in the correct direction to resolve this will be greatly appreciated.
> 
> Clark
> 
> 
Does the subject distinguished name in the signed certificate
exactly match what was in the CSR?

-- 
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] Configuring freeipa 4.4 as a subCA to in-house rootCA : ERROR IPA CA certificate not found in

2017-03-27 Thread System Administration Team 
>From old threads back in August 2016 I have been able to get closer to 
>installing freeipa server as a subCA to our in house rootCA

https://www.redhat.com/archives/freeipa-users/2016-August/msg00269.html

Running the initial install command

ipa-server-install --external-ca --domain=camgian.com 
--hostname=ipasrvr.camgian.com --realm=CAMGIAN.COM --subject 'OU=IT,O=Camgian 
Microsystems,L=Starkville,ST=Mississippi,C=US'

I am provided with /root/ipa.csr that I can signed with our rootCA

But when I run the subsequent command it fails to find the certificate in the 
chain.

ipa-server-install --external-ca --domain=camgian.com 
--hostname=ipasrvr.camgian.com --realm=CAMGIAN.COM --subject 'OU=IT,O=Camgian 
Microsystems,L=Starkville,ST=Mississippi,C=US' 
--external-cert-file=/etc/pki/tls/certs/ipasrvr.cert.pem 
--external-cert-file=/etc/pki/tls/certs/ca.cert.pem

It fails at:

ipa.ipapython.install.cli.install_tool(Server): ERRORIPA CA certificate not 
found in /etc/pki/tls/certs/ipasrvr.cert.pem, /etc/pki/tls/certs/ca.cert.pem
ipa.ipapython.install.cli.install_tool(Server): ERRORThe ipa-server-install 
command failed. See /var/log/ipaserver-install.log for more information

Any help in the correct direction to resolve this will be greatly appreciated.

Clark


-- 
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] Certificate Access issue

2017-03-27 Thread Vasily Yanov 
Hi Lukas,

You are right :) Ubuntu 16.04.

-Original Message-
From: Lukas Slebodnik [mailto:lsleb...@redhat.com] 
Sent: Tuesday, March 21, 2017 7:03 PM
To: Alexander Bokovoy 
Cc: freeipa-users@redhat.com; Artem Golubev ; IT 
Team 
Subject: Re: [Freeipa-users] Certificate Access issue

On (21/03/17 17:35), Alexander Bokovoy wrote:
>On ti, 21 maalis 2017, Lukas Slebodnik wrote:
>> On (21/03/17 16:29), Alexander Bokovoy wrote:
>> > On ti, 21 maalis 2017, Artem Golubev wrote:
>> > > We use sssd version 1.13.4 on our linux clients A user from ipa 
>> > > successfully authorizes on a linux client via ssh without a 
>> > > certificate. But then if we add a certificate - connection gets lost.
>> > If Lukas is correct, 1.13.4 does not have the fix for broken 
>> > certificate-as-ssh public key:
>> > 
>> It has.
>> https://pagure.io/SSSD/sssd/issue/2977#comment-222198
>> https://pagure.io/SSSD/sssd/c/4dbb3bec93cda57e8336847dff0822f31425004
>> d
>> 
>> It will be part of upstream release 1.13.5
>That's my point -- it is *not* part of 1.13.4, therefore, this is the 
>problem Artem sees.
>
>Artem, what is your Linux distribution? Can you move to a newer version?
>
I would gues ubuntu :-)

You might file a bug to your distribution to backport patch from the ticket 
https://pagure.io/SSSD/sssd/issue/2977

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