[Freeipa-users] FreeIPA / CentOS 7.2 / Issues on Startup

2016-08-17 Thread Devin Acosta 
My first primary FreeIPA Master server has gone belly up. When I try to
start the server it shows this message in the "error' log. However the
other issue i have is when I try to start the server using "ipactl start"
it times out after 300 seconds, how do I get past this issue?

[17/Aug/2016:22:44:57 +] SSL Initialization - Configured SSL version
range: min: TLS1.0, max: TLS1.2
[17/Aug/2016:22:44:57 +] - 389-Directory/1.3.4.0 B2016.215.1556
starting up
[17/Aug/2016:22:44:57 +] - WARNING: changelog: entry cache size
2097152B is less than db size 28016640B; We recommend to increase the entry
cache size nsslapd-cachememsize.
[17/Aug/2016:22:44:57 +] - Detected Disorderly Shutdown last time
Directory Server was running, recovering database.


Any help is greatly needed!!
-- 
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] replica_generate_next_csn messages in dirsrv error logs

2016-08-17 Thread John Desantis 
Hello all,

We've been re-using old host names and IP addresses for a new
deployment of nodes, and recently I've been seeing the messages pasted
below in the slapd-DC.DC.DC "error" log on our nodes.

[17/Aug/2016:10:30:30 -0400] - replica_generate_next_csn:
opcsn=57b475cd00120004 <= basecsn=57b475cf0016, adjusted
opcsn=57b475cf00010004
[17/Aug/2016:11:09:44 -0400] - replica_generate_next_csn:
opcsn=57b47f020004 <= basecsn=57b47f020016, adjusted
opcsn=57b47f030004
[17/Aug/2016:11:09:44 -0400] - replica_generate_next_csn:
opcsn=57b47f040004 <= basecsn=57b47f040016, adjusted
opcsn=57b47f050004
[17/Aug/2016:11:10:33 -0400] - replica_generate_next_csn:
opcsn=57b47f2f0014 <= basecsn=57b47f320016, adjusted
opcsn=57b47f330004
[17/Aug/2016:13:50:45 -0400] - replica_generate_next_csn:
opcsn=57b4a4bb00090004 <= basecsn=57b4a4bc0016, adjusted
opcsn=57b4a4bc00010004
[17/Aug/2016:13:52:54 -0400] - replica_generate_next_csn:
opcsn=57b4a53e000a0004 <= basecsn=57b4a53f0016, adjusted
opcsn=57b4a53f00010004
[17/Aug/2016:13:53:15 -0400] - replica_generate_next_csn:
opcsn=57b4a55200070004 <= basecsn=57b4a5530016, adjusted
opcsn=57b4a55300010004
[17/Aug/2016:13:53:32 -0400] - replica_generate_next_csn:
opcsn=57b4a56200090004 <= basecsn=57b4a5640016, adjusted
opcsn=57b4a56400010004

They seem to only occur when updating DNS entries, whether on the
console or via the GUI (tail -f'ing the log).

A search in this mailing-list returns nothing, but a message is found
on the 389-ds list [1];  it seems to suggest that the messages aren't
fatal and are purely informational, yet if they are occurring
constantly that there could be a problem with the replication
algorithm and/or deployment.

We're using ipa-server 3.0.0-47 and 389-ds 1.2.11.15-60.  Nothing has
changed on the deployment side of things, and I don't recall seeing
this message before.

I'm wondering if it's safe to disregard these messages due to the
re-use of the entries, or if something else should be looked into.

Thank you,
John DeSantis

[1] https://fedorahosted.org/389/ticket/47959

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

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

2016-08-17 Thread Guido Schmitz 
After some debugging, I found the error:

 cut =
ipa : DEBUGstderr=
ipa.ipapython.dnssec.bindmgr.BINDMgr: INFO attrs: {'idnsseckeyref':
['pkcs11:object=a1'], 'dn':
'cn=KSK-2014073634Z-a1,cn=keys,idnsname=myzone.com.,cn=dns,dc=int,dc=gtrs,dc=de',
'cn': ['KSK-2014073634Z-a1'], 'idnsseckeypublish':
['2014073634Z'], 'objectclass': ['idnsSecKey'], 'idnsseckeysep':
['TRUE'], 'idnssecalgorithm': ['RSASHA1NSEC3SHA1'], 'idnsseckeyzone':
['TRUE'], 'idnsseckeycreated': ['2014073634Z'],
'idnsseckeyactivate': ['2014073634Z']}
ipa : DEBUGStarting external process
ipa : DEBUGargs=/usr/sbin/dnssec-keyfromlabel-pkcs11 -K
/var/named/dyndb-ldap/ipa/master/myzone.com/tmp5dI2FC -a
RSASHA1NSEC3SHA1 -l
pkcs11:object=a1;pin-source=/var/lib/ipa/dnssec/softhsm_pin -I none
-D none -P 2014073634 -A 2014073634 -f KSK myzone.com.
ipa : DEBUGProcess finished, return code=1
ipa : DEBUGstdout=
ipa : DEBUGstderr=dnssec-keyfromlabel: fatal: unknown
algorithm RSASHA1NSEC3SHA1

Traceback (most recent call last):
  File "/usr/libexec/ipa/ipa-dnskeysyncd", line 112, in 
while ldap_connection.syncrepl_poll(all=1, msgid=ldap_search):
  File "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 409,
in syncrepl_poll
self.syncrepl_refreshdone()
  File "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py",
line 118, in syncrepl_refreshdone
self.bindmgr.sync(self.dnssec_zones)
  File "/usr/lib/python2.7/site-packages/ipapython/dnssec/bindmgr.py",
line 209, in sync
self.sync_zone(zone)
  File "/usr/lib/python2.7/site-packages/ipapython/dnssec/bindmgr.py",
line 182, in sync_zone
self.install_key(zone, uuid, attrs, tempdir)
  File "/usr/lib/python2.7/site-packages/ipapython/dnssec/bindmgr.py",
line 117, in install_key
result = ipautil.run(cmd, capture_output=True)
  File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line
479, in run
raise CalledProcessError(p.returncode, arg_string, str(output))
subprocess.CalledProcessError: Command
'/usr/sbin/dnssec-keyfromlabel-pkcs11 -K
/var/named/dyndb-ldap/ipa/master/myzone.com/tmp5dI2FC -a
RSASHA1NSEC3SHA1 -l
pkcs11:object=a1;pin-source=/var/lib/ipa/dnssec/softhsm_pin -I none
-D none -P 2014073634 -A 2014073634 -f KSK myzone.com.' returned
non-zero exit status 1
 cut =

dnssec-keyfromlabel-pkcs11 expects NSEC3RSASHA1 for algorithm 7, but it
gets RSASHA1NSEC3SHA1 instead (just the plain attribute value from LDAP).

I've changed a few lines in
/usr/lib/python2.7/site-packages/ipapython/dnssec/bindmgr.py in method
install_key:

 cut 
108c108,112
< cmd = [paths.DNSSEC_KEYFROMLABEL, '-K', workdir, '-a',
attrs['idnsSecAlgorithm'][0], '-l', uri]
---
> algo = attrs['idnsSecAlgorithm'][0]
> if algo == 'RSASHA1NSEC3SHA1':
>   algo = 'NSEC3RSASHA1'
> cmd = [paths.DNSSEC_KEYFROMLABEL, '-K', workdir, '-a', algo,
'-l', uri]
 cut 

Now, everything seems to work correctly: The DNSKEY records are
published with the correct algorithms and the ZSK is signed by both KSKs
(the imported one and the IPA generated one).

-Guido



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

[Freeipa-users] Clone URI does not match available subsystems ?

2016-08-17 Thread John Bowman 
Howdy!

Trying to figure out how to get past the error:  Clone URI does not match
available subsystems when running ipa-ca-install on new ipa server.

A little background.  We have 3 FreeIPA 3.0.0 servers running on RHEL 6.7.
We just recently (within the last month) added a new FreeIPA 4.2 server
replica running on RHEL 7.2 at a new location which will hopefully be the
start of replacing all the 3.0.0 instances.

Unfortunately during the 4.2 install the --setup-ca was failing so we
decided to install without it to make sure everything else worked.  And it
did everything seems to be replicating properly and all is good.

Now its time to add the ca replication to the new server but its failing
with that error.

Command output:
# ipa-ca-install --skip-conncheck /var/lib/ipa/replica-info-new-
server.example.com.gpg
Directory Manager (existing master) password:

Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30
seconds
  [1/22]: creating certificate server user
  [2/22]: configuring certificate server instance
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure
CA instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmp7cBK9P''
returned non-zero exit status 1
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL See the installation
logs and the following files/directories for more information:
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL
/var/log/pki-ca-install.log
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL
/var/log/pki/pki-tomcat
  [error] RuntimeError: CA configuration failed.

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

CA configuration failed.


ipareplica-ca-install.log output:
2016-08-17T15:25:52Z DEBUG stdout=Log file: /var/log/pki/pki-ca-spawn.
20160817092533.log
Loading deployment configuration from /tmp/tmp7cBK9P.
Installing CA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into /etc/sysconfig/pki/tomcat/pki-
tomcat/ca/deployment.cfg.

Installation failed.


2016-08-17T15:25:52Z DEBUG
stderr=/usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769:
InsecureRequestWarning: Unverified HTT
PS request is being made. Adding certificate verification is strongly
advised. See: https://urllib3.readthedocs.org/en/latest/security.h
tml
  InsecureRequestWarning)
pkispawn: WARNING  ... unable to validate security domain
user/password through REST interface. Interface not available
pkispawn: ERROR... Exception from Java Configuration Servlet:
400 Client Error: Bad Request
pkispawn: ERROR... ParseError: not well-formed (invalid token):
line 1, column 0: {"Attributes":{"Attribute":[]},"ClassName"
:"com.netscape.certsrv.base.BadRequestException","Code":400,"Message":"Clone
URI does not match available subsystems: https://master.idm.example.com:443
"}

2016-08-17T15:25:52Z CRITICAL Failed to configure CA instance: Command
''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmp7cBK9P'' returned n
on-zero exit status 1
2016-08-17T15:25:52Z CRITICAL See the installation logs and the following
files/directories for more information:
2016-08-17T15:25:52Z CRITICAL   /var/log/pki-ca-install.log
2016-08-17T15:25:52Z CRITICAL   /var/log/pki/pki-tomcat
2016-08-17T15:25:52Z DEBUG Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 418, in start_creation
run_step(full_msg, method)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 408, in run_step
method()
  File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
line 622, in __spawn_instance
DogtagInstance.spawn_instance(self, cfg_file)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py",
line 201, in spawn_instance
self.handle_setup_error(e)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py",
line 465, in handle_setup_error
raise RuntimeError("%s configuration failed." % self.subsystem)
RuntimeError: CA configuration failed.

2016-08-17T15:25:52Z DEBUG   [error] RuntimeError: CA configuration failed.
2016-08-17T15:25:52Z DEBUG   File "/usr/lib/python2.7/site-
packages/ipaserver/install/installutils.py", line 732, in run_script
return_value = main_function()

  File "/sbin/ipa-ca-install", line 202, in main
install_replica(safe_options, options, filename)

  File "/sbin/ipa-ca-install", line 150, in install_replica
ca.install(True, config, options)

  File "/usr/lib/python2.7/site-packages/ipaserver/install/ca.py", line
114, in install
install_step_0(standalone, replica_config, options)

  File "/usr/lib/python2.7/site-packages/ipaserver/install/ca.py", line
138, in install_step_0
ra_p12=getattr(options, 'ra_p12', None))

  File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
line 1545, in install_replica_ca
subject_base=config.subject_base)

  File

Re: [Freeipa-users] Ansible Playbook

2016-08-17 Thread Petr Vobornik 
On 08/16/2016 03:43 PM, Deepak Dimri wrote:
> Hi All,
> 
> I am looking to write ansible playbook to automatically register my EC2 
> instances as freeIPA clients to my IPA Server and then add the client(s) to a 
> particular hostgroup based on EC2 tag value. For example EC2 tag key value= 
> prod 
> will add the client to prod hostgroup. I am wondering if there is any freeIPA 
> client module available for this purpose already that i can leverage?
> 
> Many Thanks,
> Deepak
> 

Some Ansible recipes were developed by Christian for testing/demoing of
FreeIPA or Dogtag PKI:

https://github.com/tiran/pki-vagans

Might be helpful.

-- 
Petr Vobornik

-- 
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-AD ldap acces - account ?

2016-08-17 Thread Alexander Bokovoy 

On Wed, 17 Aug 2016, Jan Karásek wrote:

Hi,

please could somebody explain how and and with which account IPA is
accessing DC in IPA - AD trust scenario. Is is possible to simulate
with ldapsearch some query to AD with the same permission as IPA
server?

Depends on what trust we have. For two-way trust SSSD on IPA masters
uses host/master.ipa.domain@IPA.DOMAIN principal because we map it to a
SID with a special well-known RID 'Domain Computers' (-515) and attach
an MS-PAC record to the TGT issued for this service principal.

For one-way trust SSSD on IPA masters uses so-called TDO account. These
are special accounts in AD domains which look like a machine account
(FOO$) but instead use NetBIOS name of the trusted forest and have
specific attributes associated with it.


We have some issues with reading ldap object from AD and I would like
to simulate that from command line.


Simplest way is to do something like this on IPA master for one-way
trust:

# klist -kt /var/lib/sss/keytabs/.keytab

notice the principal name there, let's say it is NAME$@TRUST

# kinit -kt /var/lib/sss/keytabs/.keytab 'NAME$@TRUST'
# ldapsearch -H ad.dc -Y GSSAPI 

For two-way trust it is enough to kinit as IPA master host principal:

# kinit -k
# ldapsearch -H ad.dc -Y GSSAPI ...


--
/ 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] IPA-AD ldap acces - account ?

2016-08-17 Thread Jan Karásek 
Hi, 

please could somebody explain how and and with which account IPA is accessing 
DC in IPA - AD trust scenario. Is is possible to simulate with ldapsearch some 
query to AD with the same permission as IPA server? 

We have some issues with reading ldap object from AD and I would like to 
simulate that from command line. 
Thanks, 
Jan 




-- 
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-AD ldap acces - account ?

2016-08-17 Thread Jakub Hrozek 
On Wed, Aug 17, 2016 at 03:49:32PM +0200, Jan Karásek wrote:
> Hi, 
> 
> please could somebody explain how and and with which account IPA is accessing 
> DC in IPA - AD trust scenario. Is is possible to simulate with ldapsearch 
> some query to AD with the same permission as IPA server? 
> 
> We have some issues with reading ldap object from AD and I would like to 
> simulate that from command line. 
> Thanks, 
> Jan 

Identity lookups are performed by sssd running on the server. The
authentication depends on the trust type. With two-way trusts, you can just
use the system keytab. With one-way trusts, the keytab you'll want to use
to authenticate is stored at /var/lib/sss/keytabs/ and is named after the
forest. There should be a single principal there. You can authenticate with
that principal and run the same search manually. You should add -Y GSSAPI to
the ldapsearch line to make sure ldapsearch binds with GSSAPI. For example,
in my setup I use:

# ls /var/lib/sss/keytabs/
win.trust.test.keytab
# ls /var/lib/sss/keytabs/win.trust.test.keytab 
/var/lib/sss/keytabs/win.trust.test.keytab
# klist -k /var/lib/sss/keytabs/win.trust.test.keytab
Keytab name: FILE:/var/lib/sss/keytabs/win.trust.test.keytab
KVNO Principal
 --
   1 IPA$@WIN.TRUST.TEST
   1 IPA$@WIN.TRUST.TEST
   1 IPA$@WIN.TRUST.TEST
# kinit -kt /var/lib/sss/keytabs/win.trust.test.keytab 'IPA$@WIN.TRUST.TEST'
# klist 
Ticket cache: KEYRING:persistent:0:0
Default principal: IPA$@WIN.TRUST.TEST

Valid starting   Expires  Service principal
08/12/2016 09:25:07  08/12/2016 19:25:07  krbtgt/win.trust.t...@win.trust.test
renew until 08/13/2016 09:25:07
# ldapsearch -Y GSSAPI -H ldap://dc.win.trust.test -b 
CN=Administrator,CN=Users,DC=win,DC=trust,DC=test -s base tokengroups
SASL/GSSAPI authentication started
SASL username: IPA$@WIN.TRUST.TEST
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base

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

2016-08-17 Thread David Kowis 
On 08/16/2016 10:51 PM, Alexander Bokovoy wrote:
> On Tue, 16 Aug 2016, David Kowis wrote:
>> On 08/15/2016 09:27 PM, David Kowis wrote:
>>> On 08/15/2016 08:05 PM, Rob Crittenden wrote:
 David Kowis wrote:
> On 08/15/2016 04:33 AM, Petr Spacek wrote:
>> This is weird as LDAP SASL & GSSAPI is pretty standard thing.
>>
>> In any case, you can check server logs or use tcpdump/wireshark and
>> see if the
>> error somes from LDAP server or if it is client side error.
>>
>> That would tell us where to focus.
>>
>
> Welp, I've got a pile of logs for you:
> https://gist.github.com/dkowis/a82d4ec6b1823d9e1b95ffcc94666ae0
>
> The last few lines are probably the relevant ones.
>
> [15/Aug/2016:18:12:53 -0500] conn=1307 op=0 BIND dn="" method=sasl
> version=3 mech=GSSAPI
> [15/Aug/2016:18:12:53 -0500] conn=1307 op=0 RESULT err=7 tag=97
> nentries=0 etime=0
> [15/Aug/2016:18:12:54 -0500] conn=1307 op=1 UNBIND
> [15/Aug/2016:18:12:54 -0500] conn=1307 op=1 fd=68 closed - U1
>
>
> Something tries to bind with no dn, and then fails I think?

 No this is typical logging for GSSAPI (minus the error).

 The error code is LDAP_AUTH_METHOD_NOT_SUPPORTED. Do you have the cyrus
 SASL GSSAPI package installed? In Fedora the package is
 cyrus-sasl-gssapi.

>>
>> Still trying to figure stuff out:
>>
>> root@freeipavm:/var/log/dirsrv/slapd-DARK-KOW-IS# ldapsearch -h
>> localhost -p 389 -x -b "" -s base -LLL SupportedSASLMechanisms
>> dn:
>> SupportedSASLMechanisms: EXTERNAL
>>
>>
>> Should I have more than just EXTERNAL when this happens? How do I debug
>> more about what SASL authentication stuff should be there? I'm having a
>> great deal of difficulty finding documentation for the 389 directory
>> server's SASL configuration. *If* that's even the place I should be
>> looking. How can I narrow this down more?
> 389-ds does dynamically include all supported SASL mechanisms returned
> by CyrusSASL library. If you only get EXTERNAL, it means NO mechanisms
> were returned by your system SASL library. The attribute
> SupportedSASLMechanisms you see in the rootdse query above is read-only:
> it only shows which SASL mechanisms 389-ds knows about but you cannot
> influence them via this attribute. You need to look at your CyrusSASL
> library system configuration.
> 
> What does 'pluginviewer' output show?


root@freeipavm:/var/log# dpkg -l | grep sasl
ii  libsasl2-2:i386  2.1.26.dfsg1-14build1
i386 Cyrus SASL - authentication abstraction library
ii  libsasl2-modules:i3862.1.26.dfsg1-14build1
i386 Cyrus SASL - pluggable authentication modules
ii  libsasl2-modules-db:i386 2.1.26.dfsg1-14build1
i386 Cyrus SASL - pluggable authentication modules (DB)
ii  libsasl2-modules-gssapi-mit:i386 2.1.26.dfsg1-14build1
i386 Cyrus SASL - pluggable authentication modules (GSSAPI)
ii  libsasl2-modules-ldap:i386   2.1.26.dfsg1-14build1
i386 Cyrus SASL - pluggable authentication modules (LDAP)
ii  sasl2-bin2.1.26.dfsg1-14build1
i386 Cyrus SASL - administration programs for SASL users
database


# saslpluginviewer
Installed and properly configured auxprop mechanisms are:
sasldb
List of auxprop plugins follows
Plugin "sasldb" ,   API version: 8
supports store: yes

Installed and properly configured SASL (server side) mechanisms are:
  SCRAM-SHA-1 GS2-IAKERB GS2-KRB5 GSSAPI GSS-SPNEGO DIGEST-MD5 EXTERNAL
CRAM-MD5 NTLM PLAIN LOGIN ANONYMOUS
Available SASL (server side) mechanisms matching your criteria are:
  SCRAM-SHA-1 GS2-IAKERB GS2-KRB5 GSSAPI GSS-SPNEGO DIGEST-MD5 CRAM-MD5
NTLM PLAIN LOGIN ANONYMOUS
List of server plugins follows
Plugin "scram" [loaded],API version: 4
SASL mechanism: SCRAM-SHA-1, best SSF: 0, supports setpass: yes
security flags: NO_ANONYMOUS|NO_PLAINTEXT|NO_ACTIVE|MUTUAL_AUTH
features: PROXY_AUTHENTICATION|CHANNEL_BINDING
Plugin "gs2" [loaded],  API version: 4
SASL mechanism: GS2-IAKERB, best SSF: 0, supports setpass: no
security flags:
NO_ANONYMOUS|NO_PLAINTEXT|NO_ACTIVE|PASS_CREDENTIALS|MUTUAL_AUTH
features: WANT_CLIENT_FIRST|GSS_FRAMING|CHANNEL_BINDING
Plugin "gs2" [loaded],  API version: 4
SASL mechanism: GS2-KRB5, best SSF: 0, supports setpass: no
security flags:
NO_ANONYMOUS|NO_PLAINTEXT|NO_ACTIVE|PASS_CREDENTIALS|MUTUAL_AUTH
features: WANT_CLIENT_FIRST|GSS_FRAMING|CHANNEL_BINDING
Plugin "gssapiv2" [loaded], API version: 4
SASL mechanism: GSSAPI, best SSF: 56, supports setpass: no
security flags:
NO_ANONYMOUS|NO_PLAINTEXT|NO_ACTIVE|PASS_CREDENTIALS|MUTUAL_AUTH
features: WANT_CLIENT_FIRST|PROXY_AUTHENTICATION|DONTUSE_USERPASSWD
Plugin "gssapiv2" [loaded], API version: 4
SASL mechanism:

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

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

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

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

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

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

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

This verifies that key material was replicated correctly.


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

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

-- 
Petr^2 Spacek

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

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

2016-08-17 Thread Petr Spacek 
On 17.8.2016 09:52, Arthur Fayzullin wrote:
> any news?

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

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

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

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

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

5. Review the rules and load the if necessary

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

Thank you!
Petr^2 Spacek

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

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

2016-08-17 Thread Guido Schmitz 
>> Still, there is one problem:
>> My old KSK uses algorithm 7 (RSASHA1NSEC3SHA1) and IPA (by default) uses
>> algorithm 8 (RSASHA256). The old key is correctly marked as algorithm 7
>> in LDAP (under attribute idnsSecAlgorithm in the entry
>> cn=KSK-timestamp-id,cn=keys,idnsname=myzone.com,cn=dns), but BIND seems
>> to ignore this attribute and assumes that it is always algorithm 8.
> 
> Hmm, algorithm mismatch will cause DNSSEC validation to break horribly. The
> generated records will not match what is indicated in DS record of the parent
> zone...
> 
> Please look into
> /var/named/dyndb-ldap/ipa/master/myzone.com/keys
> and inspect BIND key files (*.private). Cross-check values in files with
> values shown by OpenDNSSEC. All the values should match.
> 
> If they do not match, we have a bug somewhere in the synchronization
> mechanism, which is possible.

The imported KSK does not exist in this directory (neither on the master
server nor on the replica). The keys created by IPA are present in this
directory.

Now, I also checked, if the imported KSK is used to sign the ZSK, but
there are no matching RRSIG records. (When I wrote earlier that BIND
uses the imported KSK, I only checked whether a DNSKEY record for this
KSK is present. The DNSKEY record is present, but with the wrong algorithm.)




-- 
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] Announcing bind-dyndb-ldap version 10.1

2016-08-17 Thread Petr Spacek 
The FreeIPA team is proud to announce bind-dyndb-ldap version 10.1.

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

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


Latest news:

10.1

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

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

10.0

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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


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

-- 
Petr^2 Spacek

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

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

2016-08-17 Thread Guido Schmitz 
> 
> Now it is getting interesting :-)
> 
> First of all, what version of FreeIPA packages and on what distro are you
> using? There are significant differences between package versions.

I am running Fedora 23 (inside an LXC on a Proxmox host) with FreeIPA
4.3.1 from COPR.

> 
> The export is handled by ipa-ods-exporter service on IPA DNSSEC key master
> server. Look at its logs and see if it reports any errors.
> 
> I'm not sure how OpenDNSSEC handles key import. IPA is waiting on OpenDNSSEC
> signer's socket for events which indicate key state change. If this does not
> happen the key is not exported.
> 
> You can trigger this manually by calling command
> "ods-signer ipa-full-update"
> or
> "ods-signer update "

First, when I triggered the sync, I got the following error message:

ipa-ods-exporter exception: Traceback (most recent call last):
  File "/usr/libexec/ipa/ipa-ods-exporter", line 721, in 
sync_zone(log, ldap, dns_dn, zone_name)
  File "/usr/libexec/ipa/ipa-ods-exporter", line 539, in sync_zone
ods_keys = get_ods_keys(zone_name)
  File "/usr/libexec/ipa/ipa-ods-exporter", line 278, in get_ods_keys
key_data.update(ods2bind_timestamps(row['state'], key_type, ods_times))
  File "/usr/libexec/ipa/ipa-ods-exporter", line 163, in ods2bind_timestamps
bind_times['idnsSecKeyCreated'] = ods_times['idnsSecKeyCreated']
KeyError: 'idnsSecKeyCreated'


This was caused by the field "generate" of table "keypairs" in
OpenDNSSEC's DB located at /var/opendnssec/kasp.db was empty (probably
because the key was not generated by OpenDNSSEC).

After I fixed this by entering some date into the field, the manually
triggered sync went through and the key appeared in the LDAP subtree
cn=keys,idnsname=myzone.com,cn=dns. The key, however, was still not used
by BIND.

It turned out, that I also had to set a publish time in field publish of
table dnsseckeys of /var/opendnssec/kasp.db. After this, BIND seems to
use this key now :-)



Still, there is one problem:
My old KSK uses algorithm 7 (RSASHA1NSEC3SHA1) and IPA (by default) uses
algorithm 8 (RSASHA256). The old key is correctly marked as algorithm 7
in LDAP (under attribute idnsSecAlgorithm in the entry
cn=KSK-timestamp-id,cn=keys,idnsname=myzone.com,cn=dns), but BIND seems
to ignore this attribute and assumes that it is always algorithm 8.






For documentation purposes, these are the steps I perfomed:

* Get the KSK keyfile from old setup (Kmyzone.com.+007+12345.private)

* Convert it to PEM format:
softhsm2-keyconv  --in Kmyzone.com.+007+12345.private --out ksk.pem

* Import the KSK key to SoftHSM (using the patched softhsm2-util)
sudo -u ods SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf
/usr/src/SoftHSMv2/src/bin/util/softhsm2-util  --import ksk.pem --slot
381930204 --pin $(cat /var/lib/ipa/dnssec/softhsm_pin) --label a1
--id a1

(The patched softhsm2-util used a different slot number on my system. It
usually is 0, but on my setup, the patched softhsm2-util named the slot
381930204. Note that I choose a1 as key id here. I will refer to
this id later)

* Add the key to OpenDNSSEC
sudo -u ods SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf ods-ksmutil key
import --cka_id a1 --repository SoftHSM --zone myzone.com --bits
2048 --algorithm 7 --keystate active --keytype KSK --time 20140731131634

(Note that you need to adopt some values here, depending on your key.
These are bits, algorithm and time.)

* Switch off ods-enforcerd, so we can safely modify OpenDNSSEC's DB:
service ods-enforcerd stop

* Modify OpenDNSSEC's DB to set "generate" in table "keypairs" and
"publish" in table "dnsseckeys":

sqlite3 /var/opendnssec/kasp.db
 # lookup internal key id (below I will assume that it is 1)
 select * from keypairs where HSMkey_id='a1';

 update keypairs set generate='2014-07-31 13:16:34' where id=1;

 update dnsseckeys set publish='2014-07-31 13:16:34' where keypair_id=1;

* Turn ods-enforcerd on again
service ods-enforcerd start

* Trigger full update
ods-signer ipa-full-update



-Guido

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

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

2016-08-17 Thread Arthur Fayzullin 
any news? I've tried to make selinux permissive and write new policy,
that didn't help.

require {
type ipa_var_lib_t;
type named_t;
class dir read;
class file { write open lock read getattr };
}

#= named_t ==
allow named_t ipa_var_lib_t:dir read;
allow named_t ipa_var_lib_t:file { write open lock read getattr };


22.07.2016 13:04, Roberto Cornacchia пишет:
> Ben and Petr,
>
> Thanks for your inputs, I'll keep an eye on those bug reports.
>
> Roberto
>
> On 22 July 2016 at 09:51, Petr Spacek  > wrote:
>
> On 22.7.2016 04:43, Ben Lipton wrote:
> > I'm not familiar enough with Fedora release engineering to know
> how this gets
> > fixed permanently, but I'll share some investigation I've done.
> >
> > This appears to be due to a change in the
> selinux-policy-targeted package that
> > happened recently. As of the latest version, named-pkcs11 tries
> to run as type
> > named_t instead of unconfined_service_t, but it isn't allowed to
> read the
> > files from IPA [1]. When I downgraded to the selinux-policy and
> > selinux-policy-targeted packages from [2] I was able to start
> named-pkcs11, so
> > that might be a workaround you can use for now. Ultimately, the
> patch that
> > fixes [3] might need to be backported to F23.
>
> This is being tracked as
> https://bugzilla.redhat.com/show_bug.cgi?id=1357665
>
> Stay tuned.
>
> Petr^2 Spacek
>
> >
> > Ben
> >
> > [1]
> > 
> > time->Fri Jul 22 04:17:44 2016
> > type=AVC msg=audit(1469153864.756:705): avc:  denied  { read }
> for pid=11616
> > comm="named-pkcs11" name="tokens" dev="dm-0" ino=26318195
> > scontext=system_u:system_r:named_t:s0
> > tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=dir
> permissive=1
> > 
> > time->Fri Jul 22 04:17:44 2016
> > type=AVC msg=audit(1469153864.756:706): avc:  denied  { getattr
> } for
> > pid=11616 comm="named-pkcs11"
> >
> 
> path="/var/lib/ipa/dnssec/tokens/12cfb199-b2fe-d328-0b3a-e644756b73d6/token.object"
> > dev="dm-0" ino=609982 scontext=system_u:system_r:named_t:s0
> > tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=file
> permissive=1
> > 
> > time->Fri Jul 22 04:17:44 2016
> > type=AVC msg=audit(1469153864.756:707): avc:  denied  { read
> write } for
> > pid=11616 comm="named-pkcs11" name="generation" dev="dm-0"
> ino=731584
> > scontext=system_u:system_r:named_t:s0
> > tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=file
> permissive=1
> > 
> > time->Fri Jul 22 04:17:44 2016
> > type=AVC msg=audit(1469153864.757:708): avc:  denied  { open }
> for pid=11616
> > comm="named-pkcs11"
> >
> 
> path="/var/lib/ipa/dnssec/tokens/12cfb199-b2fe-d328-0b3a-e644756b73d6/generation"
> > dev="dm-0" ino=731584 scontext=system_u:system_r:named_t:s0
> > tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=file
> permissive=1
> > 
> > time->Fri Jul 22 04:17:44 2016
> > type=AVC msg=audit(1469153864.757:709): avc:  denied  { lock }
> for pid=11616
> > comm="named-pkcs11"
> >
> 
> path="/var/lib/ipa/dnssec/tokens/12cfb199-b2fe-d328-0b3a-e644756b73d6/generation"
> > dev="dm-0" ino=731584 scontext=system_u:system_r:named_t:s0
> > tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=file
> permissive=1
> >
> > [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=758088
> > [3] https://bugzilla.redhat.com/show_bug.cgi?id=1333106
> >
> > On 07/21/2016 05:51 PM, Roberto Cornacchia wrote:
> >> UPDATE:
> >>
> >> Tried again the whole procedure with ipa-dns-install, and it
> DOES work with
> >> SElinux disable, and still fails with SElinux enabled.
> >>
> >> So the error "Failed to enumerate object store in
> /var/lib/softhsm/tokens/"
> >> makes sense.
> >>
> >> Can someone help me fix it?
> >>
> >> $ ll -Z /var/lib/ipa/dnssec/
> >> total 12
> >> -rwxrwx---. 1 ods named unconfined_u:object_r:ipa_var_lib_t:s0 
>  30 Jul 21
> >> 22:50 softhsm_pin*
> >> drwxrws---. 3 ods named unconfined_u:object_r:ipa_var_lib_t:s0
> 4096 Jul 21
> >> 22:50 tokens/
> >>
> >>
> >>
> >> On 21 July 2016 at 23:11, Roberto Cornacchia
> 
> >>  >> wrote:
> >>
> >> - FC23
> >> - IPA 4.2.4
> >>
> >> After a dnf update, bind was updated (no ipa updates),
> >> and named-pkcs11 doesn't start anymore.
> >>
> >>
> >> $ /usr/sbin/named-pkcs11 -d 9 -g
> >> 21-Jul-2016 23:08:50.332 starting BIND
> >>

Re: [Freeipa-users] FreeIPA vs DogTag CA

2016-08-17 Thread Fraser Tweedale 
On Wed, Aug 17, 2016 at 10:52:53AM +0530, Kaamel Periora wrote:
> Thanks.
> 
> One last question :)
> 
> Will that be feasible to have all the systems (CA, RA, OCSP) on top of
> fedora and upgrade the OS as well as CS with the latest ones time to time.
> This should not affect the exiting data or configuration. With Fedora this
> seems to be a must.
> 
It is feasible, and if you want to stay on supported releases you
will need to do it more frequently on Fedora than on RHEL or CentOS,
because Fedora evolves faster and orphans old releases more eagerly.
Your choice depends on your organisation's technical requirements
and risk appetite ;)

Thanks,
Fraser

> On Tue, Aug 16, 2016 at 5:25 PM, Fraser Tweedale 
> wrote:
> 
> > On Tue, Aug 16, 2016 at 04:29:02PM +0530, Kaamel Periora wrote:
> > > Thanks Fraser.
> > >
> > > So basically i can rule out FreeIPA and go ahead with DogTag.
> > >
> > > According to our security requirements, it is not wise to let the genral
> > > public access to the OCSP service running on the CA. I suppose having an
> > > OCSP over Fedora while the others run on CentOS would do.
> > >
> > Sure, you can deploy it that way.  I do not know of anyone who has
> > done so but it should work.
> >
> > > how about RA, can i have it over CentOS?
> > >
> > We no longer have a separate RA subsystem.  RA capabilities are
> > conceptually part of the CA subsystem now.
> >
> > > On Tue, Aug 16, 2016 at 3:04 PM, Fraser Tweedale 
> > > wrote:
> > >
> > > > On Tue, Aug 16, 2016 at 02:54:41PM +0530, Kaamel Periora wrote:
> > > > > Thanks Rob and Fraser, appreciate your time in replying.
> > > > >
> > > > > Currently we are not using FreeIPA but dogtag 9 as an standalone
> > system
> > > > > with RA and OCSP as well.
> > > > >
> > > > > We thought of migrating to the FreeIPA after looking at the the ease
> > of
> > > > > management and excellent support community behind.
> > > > >
> > > > > We require SSL/TLS server certificates and user certificates as well.
> > > > >
> > > > > Currently our major issue is the continuous changes (not stable) in
> > the
> > > > > underlying OS which is Fedora. If we proceed with Dogtag over CentOS
> > or
> > > > > RedHat, will that suffice the stability requirements while
> > delivering the
> > > > > same level of integration with Fedora?
> > > > >
> > > > > your opinion is much appreciated.
> > > > >
> > > > > Kaamel
> > > > >
> > > > FreeIPA and Dogtag are both available in RHEL and CentOS, so you can
> > > > have FreeIPA's ease of management on a less rapidly-evolving
> > > > platform.
> > > >
> > > > Caveat: the standalone OCSP subsystem is not supported on RHEL, but
> > > > the CA subsystem has an inbuilt OCSP responder which may suffice.
> > > >
> > > > Thanks,
> > > > Fraser
> > > >
> > > > > On Fri, Aug 12, 2016 at 6:10 AM, Fraser Tweedale <
> > ftwee...@redhat.com>
> > > > > wrote:
> > > > >
> > > > > > On Thu, Aug 11, 2016 at 11:54:25AM -0400, Rob Crittenden wrote:
> > > > > > > Kamal Perera wrote:
> > > > > > > > Dear all,
> > > > > > > >
> > > > > > > > Seeking your kind advices.
> > > > > > > >
> > > > > > > > If the requirement is for having a scalable corporate CA only,
> > is
> > > > it
> > > > > > > > possible to get this requirement fulfilled with DogTag only, or
> > > > install
> > > > > > > > FreeIPA and use the CA functionality only.
> > > > > > >
> > > > > > > IPA limits dogtag to only those features it is interested in.
> > This
> > > > has
> > > > > > been
> > > > > > > expanding recently but you still lose some functionality.
> > > > > > >
> > > > > > > IMHO if all you want is a CA then managing IPA is overkill.
> > > > > > >
> > > > > > > > What are the functional differences and support limitations?
> > > > > > >
> > > > > > > Functionally it depends on what version of IPA you're talking
> > about.
> > > > > > Older
> > > > > > > versions only exposed server certificates. Newer versions support
> > > > user
> > > > > > > certifications, custom profiles and more. It is still just a
> > subset
> > > > of
> > > > > > what
> > > > > > > dogtag supports.
> > > > > > >
> > > > > > > Support from whom? The dogtag community is happy to help (they've
> > > > always
> > > > > > > helped us).
> > > > > > >
> > > > > > There are lots of questions that can help you decide which path to
> > > > > > take: what kinds of certs do you want to issue; to what entities;
> > > > > > who will issue them; are you already using FreeIPA in your
> > > > > > organisation?
> > > > > >
> > > > > > In regards to functional differences, Dogtag CA and KRA are
> > > > > > supported with FreeIPA; token processing and standalone OCSP are
> > > > > > not.  I disagree somewhat with Rob in that unless you need those
> > > > > > other Dogtag subsystems, I see little disadvantage in using
> > FreeIPA.
> > > > > > It definitely makes deploying the CA easier and managing renewals
> > > > > > easier.
> > > > > >
> > > > > > The more you tell us