Re: [Freeipa-users] Certificate profiles and CA ACLs for service principals

[Alexander Bokovoy]

On Tue, 22 Mar 2016, Fraser Tweedale wrote:

On Fri, Mar 18, 2016 at 08:12:44PM +1100, earsdown wrote:

Hi all,

Firstly, a big thank you to everyone who works on the FreeIPA project - you
guys are my heroes.

Let's talk about the new Certificate Profile and CA ACL feature and some use
cases that should be possible but I'm struggling to implement. Hopefully I'm
just missing something obvious, and if not, perhaps someone here can suggest
a workaround. I'll do my best to keep this as brief and concise as possible,
and I'm grateful for any help given.

Some background:

Our environment is composed of AWS EC2 instances running CentOS 7 (7.2.1511
+ ipa-server-4.2.0-15, fully patched afaik).
Our instances acquire three certificates during creation, which is achieved
via user-data/cloud-init. The first certificate is linked to service
principal puppet/$HOSTNAME, the second is linked to HTTP/$HOSTNAME, and the
third is the default NSS-based certificate linked to the host principal (via
ipa-client-install --request-cert).
We want our long-lived EC2 instances to acquire certificates using the
standard caIPAserviceCert profile. Examples would be database servers,
puppetmasters, etc.
We use EC2 spot instances via auto-scaling groups heavily - these are our
short-lived instances. For example, application servers, etc.
We want our short-lived instances to acquire certificates with a really
short validity (like 3 days). Read on to find out why.

Our applications login to their respective postgresql databases using mutual
SSL auth (i.e. IPA CA issued certificates). Sadly, postgresql has to be
restarted every time the CRL is updated (see section 17.9.2 of postgresql
doc). If the CRL expires, postgres stops authenticating clients via SSL.
This means we're forced to either turn off CRL checking in postgres entirely
or have really long CRL validity times - we're going to go with the latter.
It also means application servers will need to be issued with short-lived
certificates (and must not have access to the caIPAserviceCert profile)
because we can't realistically restart our production database servers every
time an application server's certificate gets revoked.

The use case:

1. Suppose we have a hostgroup called "database_servers" and a host called
"db01" that is a member.
3. Modify the default CA ACL "hosts_services_caIPAserviceCert" to restrict
access to the "database_servers" hostgroup only (i.e. no services or users
allowed).
4. Attempt to request a certificate (via ipa-getcert) from the "db01" server
(which is in the "database_servers" hostgroup). The request should be linked
(via -K) to a service principal like postgres/$HOSTNAME (service to be
created beforehand).
5. This currently fails with CA_REJECTED ca-error: Server at
https://ipa.example.com/ipa/xml denied our request, giving up: 2100 (RPC
failed at server.  Insufficient access: Principal
'postgres/db01.example@example.com' is not permitted to use CA '.' with
profile 'caIPAserviceCert' for certificate issuance.).

Is this the intended behaviour? If so, is there any way to avoid having to
add each and every individual service principal directly to the CA ACL?
After all, we have hostgroups to avoid the mess of adding individual hosts,
right? Well... each host would have several service principals...and we
don't seem to have a way of grouping them.

Thanks in advance,

~earsdown


Hi,

This is expected behaviour.  The CA ACLs control which profiles may
be used with which subject principals, which in your use case is a
service principal.  Adding the host or hostgroup to the CA ACL does
not apply to service principals, even though the hostname may be the
same.

For grouping services, FreeIPA currently does not have a "group"
object for service principals.  So at the moment, either every
applicable service must be added to the ACL, or you can allow all
services with the command: 'ipa caacl-mod  --servicecat=all'.

I hope that explains the situation clearly.  Let me know your
follow-up questions!

To my fellow FreeIPA developers: are service groups a sensible RFE?
Is there a reason why they have not been implemented?

I don't think you need to group services this way. For managing
services, and this means being able to issue certificates/keytabs for
them, we have hosts. By default a host that a service belongs to is
capable to modify userCertificate attribute of the service already, so I
would expect it to be able to issue certificates with subject principal
corresponding to the service.

If CAACL would follow the same logic by allowing hosts that manage
services to issue certificates with subject principals corresponding to
these services, that should be enough because, after all, these host
objects already have write permissions and can upload whatever
certificates they like to the service objects.
--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to 

Re: [Freeipa-users] Renewing an externally signed HTTP/LDAP certificate

[Rob Crittenden]

Joseph Timothy Foley wrote:

I just discovered that the certificate on ipa2.cs.ru.is is good to August,
so I have a little bit of breathing room.  That said, the ipa.cs.ru.is
certificate will expire on March 23, so I need to update it.


The process to get a new cert is pretty much the same as you obtained 
the original assuming you kept the original CSR. You'd re-submit that to 
StartSSL and they will provide a new certificate in PEM format.


Add that to the relevant database via:

# certutil -A -n "Server-Cert" -d /path/to/db -t u,u,u -a -i /path/to 
cert.pem


I can't give much more specific information without knowing if you are, 
for example, using the came cert/key for both 389-ds and Apache.


rob


--
Dr. Joseph T. Foley  Assistant Professor,  Reykjavik
University +354-599-6569



On 3/21/16 6:27 PM, "Joseph Timothy Foley"  wrote:


Hi there.
I setup an IPA4.2.0 on RHEL7 service for our CS department on
ipa.cs.ru.is(temporarily down) and ipa2.cs.ru.is
I used StartSSL to sign our certificate for HTTP and LDAP usage because I
didn't want our users to deal with the internal CA nor could we get the CA
certificate signed.  Problem is, I can't find any information on how to
get the new certificates installed on the running IPA server.  They expire
in 2 days, so I'm running out of time. Any help would be greatly
appreciated.

I can only find information on how to setup these certificates on a brand
new IPA or replicant.  There isn't any obvious information on how to put
updated certificates into a running instance.

Thanks in advance.

Joe
--
Dr. Joseph T. Foley  Assistant Professor,  Reykjavik
University +354-599-6569




--
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] Renewing an externally signed HTTP/LDAP certificate

[Joseph Timothy Foley]

I just discovered that the certificate on ipa2.cs.ru.is is good to August,
so I have a little bit of breathing room.  That said, the ipa.cs.ru.is
certificate will expire on March 23, so I need to update it.
--
Dr. Joseph T. Foley  Assistant Professor,  Reykjavik
University +354-599-6569



On 3/21/16 6:27 PM, "Joseph Timothy Foley"  wrote:

>Hi there.
>I setup an IPA4.2.0 on RHEL7 service for our CS department on
>ipa.cs.ru.is(temporarily down) and ipa2.cs.ru.is
>I used StartSSL to sign our certificate for HTTP and LDAP usage because I
>didn't want our users to deal with the internal CA nor could we get the CA
>certificate signed.  Problem is, I can't find any information on how to
>get the new certificates installed on the running IPA server.  They expire
>in 2 days, so I'm running out of time. Any help would be greatly
>appreciated.
>
>I can only find information on how to setup these certificates on a brand
>new IPA or replicant.  There isn't any obvious information on how to put
>updated certificates into a running instance.
>
>Thanks in advance.
>
>Joe
>--
>Dr. Joseph T. Foley  Assistant Professor,  Reykjavik
>University +354-599-6569
>
>
>
>
>-- 
>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] Renewing an externally signed HTTP/LDAP certificate

[Joseph Timothy Foley]

Hi there.
I setup an IPA4.2.0 on RHEL7 service for our CS department on
ipa.cs.ru.is(temporarily down) and ipa2.cs.ru.is
I used StartSSL to sign our certificate for HTTP and LDAP usage because I
didn't want our users to deal with the internal CA nor could we get the CA
certificate signed.  Problem is, I can't find any information on how to
get the new certificates installed on the running IPA server.  They expire
in 2 days, so I'm running out of time. Any help would be greatly
appreciated.

I can only find information on how to setup these certificates on a brand
new IPA or replicant.  There isn't any obvious information on how to put
updated certificates into a running instance.

Thanks in advance.

Joe
--
Dr. Joseph T. Foley  Assistant Professor,  Reykjavik
University +354-599-6569




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

[Petr Vobornik]

The FreeIPA team would like to announce FreeIPA v4.2.4 bug fixing release!

It can be downloaded from http://www.freeipa.org/page/Downloads. The 
builds are available for Fedora 23.


https://bodhi.fedoraproject.org/updates/freeipa-4.2.4-1.fc23

This release notes are also available on 
http://www.freeipa.org/page/Releases/4.2.4


== Highlights in 4.2.4 ==

FreeIPA 4.2.4 is a bugfix release to improve upgrade experience from 
FreeIPA 4.1 for Fedora 23.


=== Bug fixes ===
* Fixed issue in installation of server with external CA where second 
step of installation "forgot" options from previous step which could 
lead, e.g., to DNS server not being installed. #5556
* Fixed issue in ipa-adtrust-install when a dash character was used in 
NetBIOS name
* Fixed issue with migration from old self-sign IPA(e.g. CentOS 6) and 
upgrading it to a server with CA #5611, #5598, #5602, #5595, #5636, 
#4492, #5506
* Fixed issue with bind not starting after update due to wrong file 
permissions. #5520
* Fixed issue in installation of server without CA when certmonger was 
not running. #5519

* Fixed issue in upgrade of NIS maps. #5507
* Fixed issue in handling of empty cookies. It prevented users from log 
in to Web UI using forms-based authentication. #5709

* Fixed issue with installation of KRA on a replica. #5346
* Fixed issue with DNSSEC key purging not being handled properly #5334
* Fixed issue in replica installation after update of master from 
previous version where certificate profiles and CA ACL were not properly 
added. #5269
* Fixed issue in installation of replica with external CA, when multiple 
certificates with the same nickname were provided. #5117
* Fixed issue after upgrade of sidgen and extdom plugins which prevented 
from generation of Security Identifiers(SIDs). As a result, all AD trust 
created after the upgrade did not work while advertising that the trust 
was established correctly. #5665
* Fixed issue with starting FreeIPA after upgrade which happened when 
FreeIPA server was turned off. #5655
* Fixed internal error during an upgrade from FreeIPA 4.0 to 4.2 which 
prevented the upgrade process from upgrading forward zones properly. #5472
* Fixed issue with missing "System: Read Replication Agreements" ACI on 
new replicas. #5631
* Fixed issue on Web UI password reset page where user was not notified 
when he entered invalid password #5567


=== Enhancements ===
* ipa-replica-prepare and ipa-replica-install no longer fails if PTR 
record is not resolvable #5686


== Upgrading ==
Upgrade instructions are available on upgrade 
page.


== Feedback ==
Please provide comments, bugs and other feedback via the freeipa-users 
mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or 
#freeipa channel on Freenode.


== Detailed Changelog since 4.2.3 ==
=== Abhijeet Kasurde (2) ===
* Fixed small typo in stage-user documentation
* Fixed login error message box in LoginScreen page

=== Alexander Bokovoy (1) ===
* slapi-nis: update configuration to allow external members of IPA groups

=== Christian Heimes (1) ===
* Require Dogtag 10.2.6-13 to fix KRA uninstall

=== David Kupka (5) ===
* ipa-cacert-renew: Fix connection to ldap.
* ipa-otptoken-import: Fix connection to ldap.
* test: Temporarily increase timeout in vault test.
* installer: Propagate option values from components instead of copying 
them.

* installer: Fix logic of reading option values from cache.

=== Fraser Tweedale (5) ===
* TLS and Dogtag HTTPS request logging improvements
* Avoid race condition caused by profile delete and recreate
* Do not erroneously reinit NSS in Dogtag interface
* Add profiles and default CA ACL on migration
* Do not decode HTTP reason phrase from Dogtag

=== Gabe Alford (2) ===
* Incomplete ports for IPA AD Trust
* Check if IPA is configured before attempting a winsync migration

=== Jan Cholasta (9) ===
* install: fix command line option validation
* install: export KRA agent PEM file in ipa-kra-install
* cert renewal: make renewal of ipaCert atomic
* client install: do not corrupt OpenSSH config with Match sections
* ipalib: assume version 2.0 when skip_version_check is enabled
* cert renewal: import all external CA certs on IPA CA cert renewal
* CA install: explicitly set dogtag_version to 10
* replica install: validate DS and HTTP server certificates
* certdb: never use the -r option of certutil

=== Lenka Doudova (2) ===
* Adding descriptive IDs to stageuser tests
* Tests: Fix tests for (stage)user plugin

=== Martin Babinsky (13) ===
* fix error reporting when installer option is supplied with invalid choice
* suppress errors arising from adding existing LDAP entries during KRA 
install

* update idrange tests to reflect disabled modification of local ID ranges
* disconnect ldap2 backend after adding default CA ACL profiles
* do not disconnect when using existing connection to check default CA ACLs
* fix error message assertion in negative forced client 

Re: [Freeipa-users] Tracking Login Times

[Rob Crittenden]

Bob wrote:

We currently have 18 master ODSEE servers that we use to provide authentication 
services to both Redhat, SuSE, and Solaris systems. We are looking to add IPA 
servers to
environment.

We have a requirement to track time of last authentication.  With ODSEE, time 
of last authentication tracking is enabled with this:

*dsconf set-server-prop pwd-keep-last-auth-time-enabled:on*


Looking at the Redhat DS 9 documentation, I see an account policy plug-in:


cn=Account Policy Plugin,cn=plugins,cn=config

Looking thefreeipa.org   pages on the server plugins, I do 
not see the account policy plugin listed.
http://www.freeipa.org/page/Directory_Server

Looking in the directory DT of a "VERSION: 4.2.0, API_VERSION: 2.156" installed 
on Redhat 7, I do see the account policy plugin in the config tree.


Is the use of this account policy plugin supported with IPA? Should it work?


IPA has its own password policy. You can get last successful 
authentication via krbLastSuccessfulAuth


Don't let the attribute name mislead you, it is updated on every 
authentication.


Also note that this is per-IPA master. It is not replicated.

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] Tracking Login Times

[Bob]

We currently have 18 master ODSEE servers that we use to provide
authentication services to both Redhat, SuSE, and Solaris systems. We
are looking to add IPA servers to environment.

We have a requirement to track time of last authentication.  With
ODSEE, time of last authentication tracking is enabled with this:


*dsconf set-server-prop pwd-keep-last-auth-time-enabled:on*

Looking at the Redhat DS 9 documentation, I see an account policy plug-in:


cn=Account Policy Plugin,cn=plugins,cn=config

Looking the freeipa.org pages on the server plugins, I do not see the
account policy plugin listed.
http://www.freeipa.org/page/Directory_Server

Looking in the directory DT of a "VERSION: 4.2.0, API_VERSION: 2.156"
installed on Redhat 7, I do see the account policy plugin in the
config tree.


Is the use of this account policy plugin supported with IPA? Should it work?

Thanks,

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

Re: [Freeipa-users] Unable to authenticate

[Lukas Slebodnik]

On (19/03/16 21:58), pgb205 wrote:
>I have enabled debugging withdebug_level = 7 in sssd.conf
>Receive following error messages:Marking server 'ipa-server' as 'name 
>resolved'[be_resolve_server_process] (0x0200): Found address for server 
>ipa-server
>[get_port_status] (0x1000): Port status of port 389 for server 'ipa-server' is 
>'not working'
>
It would be good to find a reason why port 389 for server 'ipa-server' is 'not
working'.

Try to follow instructions from wiki
https://fedorahosted.org/sssd/wiki/Troubleshooting

LS

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

Re: [Freeipa-users] Directory Search Question

[Martin Kosek]

On 03/18/2016 09:21 PM, Randy Morgan wrote:
> We have a FreeIPA Version 4.2 production installation that seems to have a
> limitation we cannot figure out how to overcome.  Users cannot search, from 
> the
> gui, for a specific user.  The only users who can perform a search for a
> specific user are full-admins, everyone else the search option does not
> respond, meaning that if you click on the magnifying glass, nothing happens. 
> We have a large number of groups, and they are managed by the group owner, who
> needs to be able to do a user search.  This appears to be a permissions issue,
> but we are not sure what we need to change to make it so that we can assign
> search capability to specific user groups.  Any help would be greatly 
> appreciated.

Hello Randy,

What permissions have you defined to allow your group admins to administer the
groups?

On my RHEL-7.2 machine, I tried setting up delegation like that:

# kinit admin
Password for admin@RHEL72:
# ipa group-add lab
# ipa permission-add --type group --right write --filter "(cn=lab)" --attrs
member can_manage_lab

# ipa user-add --first Lab --last Admin labadmin
# ipa passwd labadmin
# ipa role-add labadmin
# ipa privilege-add labadmin
# ipa role-add-member labadmin --users labadmin
# ipa role-add-privilege labadmin --privilege labadmin
# ipa privilege-add-permission labadmin --permissions labadmin
# ipa privilege-add-permission labadmin --permissions can_manage_lab
# ipa user-show labadmin
...
  Roles: labadmin
# ipa user-add --first Lab --last User labuser1
# ipa user-add --first Lab --last User labuser2

# kinit labadmin
Password for labadmin@RHEL72:
Password expired.  You must change it now.
Enter new password:
Enter it again:
# ipa group-add-member lab --users labuser1
  Group name: lab
  GID: 63241
  Member users: labuser1
-
Number of members added 1
-

When I tried to achieve similar with labadmin on
https://ipa.rhel72/ipa/ui/#/e/group/member_user/lab
it worked for me as well and I was able to manage lab group members in the UI.

HTH,
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] sssd.service start operation timed out

[Lukas Slebodnik]

On (20/03/16 13:00), Harald Dunkel wrote:
>Hi Lukas,
>
>On 03/19/16 10:59, Lukas Slebodnik wrote:
>> On (19/03/16 10:38), Harald Dunkel wrote:
>> 
>>> Since freeipa doesn't work with anything else but systemd its a little bit 
>>> cheap now to say "not my problem", is it?
>>> 
>> "freeipa-server" doesn't work with anything else but systemd. and 
>> freeipa-client just configure sssd and few other services.
>> 
>
>Without systemd:
>
>root@lxc31:~# ipa-client-install
>Traceback (most recent call last):
>  File "/usr/sbin/ipa-client-install", line 2790, in 
>sys.exit(main())
>  File "/usr/sbin/ipa-client-install", line 2771, in main
>rval = install(options, env, fstore, statestore)
>  File "/usr/sbin/ipa-client-install", line 2006, in install
>ipaclient.ntpconf.check_timedate_services()
>  File "/usr/lib/python2.7/dist-packages/ipaclient/ntpconf.py", line 183, in 
> check_timedate_services
>if instance.is_enabled() or instance.is_running():
>  File "/usr/lib/python2.7/dist-packages/ipaplatform/base/services.py", line 
> 321, in is_enabled
>self.service_instance(instance_name)])
>  File "/usr/lib/python2.7/dist-packages/ipapython/ipautil.py", line 321, in 
> run
>preexec_fn=preexec_fn)
>  File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
>errread, errwrite)
>  File "/usr/lib/python2.7/subprocess.py", line 1335, in _execute_child
>raise child_exception
>OSError: [Errno 2] No such file or directory
>
>
>Of course I understand that writing portable software is a
>difficult task, but is this restriction really necessary, if
>ipa client support is about "just configure sssd and a few
>other services"? Currently I have to install systemd to make
>ipa-client-install work, and later I can move back to sysvinit
>to support HA services.
>
But it's not problem of sssd. And it's not related to you issue with
LXC containers.

It's problem of ipa-client-install

Feel free to send patches which make freeipa-client more portable
http://www.freeipa.org/page/Contribute/Code

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