[Freeipa-users] Announcing FreeIPA v3.1.0 Release

[Rob Crittenden]

The FreeIPA team is proud to announce version FreeIPA v3.1.0.

It can be downloaded from http://www.freeipa.org/page/Downloads.

A build will be submitted to updates-testing for Fedora 18 soon.

== Highlights in 3.1.0 ==

* A single 389-ds instance is used both for IPA identity data and for 
the dogtag CA server on new installs.

* Support for Windows 2012 Server Trusts.
* Verify that the IPA certificates are not tracked by certmonger after 
server uninstallation.

* Enable 389-ds transactions.
* If chronyd is running on a server disable it and replace it with ntpd 
by default.
* Add new OCSP and CRL URIs to the IPA certificate profile for a new 
CNAME entry, ipa-ca.example.com.
* Fix potential security error in cookie handling in ipa client tool, 
CVE-2012-5631.


== Upgrading ==

An IPA server can be upgraded simply by installing updated rpms. The 
server does not need to be shut down in advance.


Please note, that the referential integrity extension requires an 
extended set of indexes to be configured. RPM update for an IPA server 
with a excessive number of hosts, SUDO or HBAC entries may require 
several minutes to finish.


If you have multiple servers you may upgrade them one at a time. It is 
expected that all servers will be upgraded in a relatively short period 
(days or weeks not months). They should be able to co-exist peacefully 
but new features will not be available on old servers and enrolling a 
new client against an old server will result in the SSH keys not being 
uploaded.


Downgrading a server once upgraded is not supported.

Upgrading from 2.2.0 is supported. Upgrading from previous versions is 
not supported and has not been tested.


Upgrading from a previous version will not consolidate the 389-ds 
instances. Only new installations get a unified 389-ds backend. Upgraded 
servers will retain both instances.


An enrolled client does not need the new packages installed unless you 
want to re-enroll it. SSH keys for already installed clients are not 
uploaded, you will have to re-enroll the client or manually upload the keys.


== Feedback ==

Please provide comments, bugs and other feedback via the freeipa-devel 
mailing list: http://www.redhat.com/mailman/listinfo/freeipa-devel


== Detailed Changelog since 3.0.1 ==

Ade Lee (1):
* Changes to use a single database for dogtag and IPA

Alexander Bokovoy (8):
* ipa-kdb: Support Windows 2012 Server
* Remove bogus check for smbpasswd
* Warn about DNA plugin configuration when working with local ID ranges
* Resolve external members from trusted domain via Global Catalog
* Clarify trust-add help regarding multiple runs against the same domain
* ipasam: better Kerberos error handling in ipasam
* trusts: replace use of python-crypto by m2crypto
* Propagate kinit errors with trust account

Endi Sukma Dewata (1):
* Configuring CA with ConfigParser.

Jakub Hrozek (5):
* ipa-client-automount: Add the autofs service if it doesn't exist yet
* Make enabling the autofs service more robust
* ipachangeconf: allow specifying non-default delimeter for options
* Specify includedir in krb5.conf on new installs
* Add the includedir to krb5.conf on upgrades

Jan Cholasta (1):
* Reword description of the --passsync option of ipa-replica-manage.

John Dennis (2):
* log dogtag errors
* Compliant client side session cookie behavior

Lubomir Rintel (1):
* Drop unused readline import

Martin Kosek (18):
* Update SELinux policy for dogtag10
* Bump 389-ds-base minimum in our spec file
* Add OCSP and CRL URIs to certificates
* Stop and disable conflicting time&date services
* Create reverse zone in unattended mode
* Add fallback for httpd restarts on sysV platforms
* Report ipa-upgradeconfig errors during RPM upgrade
* Avoid uninstalling dependencies during package lifetime
* Remove servertrls and clientctrls options from rename_s
* Use common encoding in modlist generation
* Process relative nameserver DNS record correctly
* Do not require resolvable nameserver in DNS install
* Disable global forwarding per-zone
* Prepare spec file for Fedora 18
* Filter suffix in replication management tools
* Change network configuration file
* Improve ipa-replica-prepare error message
* Fix sshd feature check

Nikolai Kondrashov (1):
* Add uninstall command hints to ipa-*-instal

Petr Viktorin (12):
* Fix schema replication from old masters
* Use correct Dogtag configuration in get_pin and get_ca_certchain
* Update certmap.conf on IPA upgrades
* Properly stop tracking certificates on uninstall
* Provide 'protocol' argument to IPAdmin
* Make ipa-csreplica-manage work with both merged and non-merged DBs
* Use DN objects for Dogtag configuration
* ipautil.run: Log the command line before running the command
* ipa-replica-install: Use configured IPA DNS servers in forward/reverse 
resolution check

* Make sure the CA is running when starting services
* Provide explicit user name for Dogtag installation scripts
* Add Lubomir Rintel to Contributors.txt

Petr Vobornik (7):
* Simple

Re: [Freeipa-users] cross realm trust - SID doesn't resolve

[Dmitri Pal]

On 12/10/2012 12:04 PM, Brian Cook wrote:
> Okay, I'll open an RFE.  Fwiw, when AD can't resolve a SID for any reason, it 
> does display the SID itself but only as a fallback mechanism.  I think this 
> would be acceptable behavior.


Now I think you understand why it is a tech preview.
You hit right away couple things that QE was also expecting to work.

>
> -Brian
>
>
>
> On Dec 10, 2012, at 4:12 AM, Alexander Bokovoy  wrote:
>
>> On Sun, 09 Dec 2012, Brian Cook wrote:
>>> Good to know my setup is working, but for administration purposes
>>> displaying a SID in the GUI is as useless as displaying UID's with no
>>> user name.  SID's are not meant for human eyes.  Is there some issue
>>> with resolving it to the name and displaying the name instead?  Should
>>> I open an RFE?
>> Since resolving SID means contacting AD's global catalog, there might be
>> delays and even failure. I'll see how we can do it in a safe way.
>>
>> Please add an RFE.
>>
>> -- 
>> / Alexander Bokovoy
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] cross realm trust - SID doesn't resolve

[Brian Cook]

Okay, I'll open an RFE.  Fwiw, when AD can't resolve a SID for any reason, it 
does display the SID itself but only as a fallback mechanism.  I think this 
would be acceptable behavior.

-Brian



On Dec 10, 2012, at 4:12 AM, Alexander Bokovoy  wrote:

> On Sun, 09 Dec 2012, Brian Cook wrote:
>> Good to know my setup is working, but for administration purposes
>> displaying a SID in the GUI is as useless as displaying UID's with no
>> user name.  SID's are not meant for human eyes.  Is there some issue
>> with resolving it to the name and displaying the name instead?  Should
>> I open an RFE?
> Since resolving SID means contacting AD's global catalog, there might be
> delays and even failure. I'll see how we can do it in a safe way.
> 
> Please add an RFE.
> 
> -- 
> / Alexander Bokovoy


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] how to allow a remote realm user to be an IPA admin?

[Simo Sorce]

On Mon, 2012-12-10 at 14:25 +0200, Alexander Bokovoy wrote:
> On Sun, 09 Dec 2012, Brian Cook wrote:
> >How do you let a remote user be an admin for IPA?
> You cannot do it, at least right now.
> 
> >
> >I followed the fedora group example
> >
> >external group:ad_admins_external
> >Posix Group: ad_admins
> >
> >Then I made ad_admins a group member of ipa group 'admins' -
> >theoretically now MSAD\Administrator is an IPA admin?  I get the
> >following.  How does this work?
> 
> Being able to perform IPA management operations means being able to bind
> to IPA LDAP with the identity in question. For Kerberos authentication
> LDAP server maps user principal to a DN of an object in LDAP.
> 
> In case of trust users there are no LDAP objects that they represent
> since the whole idea of a trust was to avoid replicating objects between
> the realms, so while IPA KDC accepts AD realm's tickets for the users,
> IPA LDAP server doesn't know what they map to in terms of LDAP objects.
> 
> Thus, trust users cannot be used to bind for LDAP access.

Note that this[1] DS tickeet needs to be implemented for us to be able,
at some point to create a fallback mapping so we can map foreign user to
a 'role' object in DS. This way we will be able to properly authorize
remote users to operate on freeipa, even as admins at some point as long
as we can map them to an object role based on a SAL mapping.

This will take a while though. For the moment you need a real FreeIPA
user to manage freeipa, you can think of foreign uses as 'guests' atm.

Simo.


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

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Cmd-line Unprovision & OTP setting for a host

[Dmitri Pal]

On 12/07/2012 10:15 PM, Charlie Derwent wrote:
> Sorry for the extremely late reply, rebuilds of clients, keytab and
> configuration primarily but certs too would be nice.
>  
> What we currently do during our provisioning process is disable the
> host and reset the password (as previously mentioned) during the
> kickstart setup process so the server can successfully enroll (or in
> the situation I'm thinking of re-enroll) later on. The problem that
> causes is when you need to log onto the server to reboot it but you've
> just removed your account. So we have to use a shared local account
> to log on, limiting the need to do things like that was the exact
> reason we installed IPA on our network in the first place.
>  
> So if there was a command like ipa-client-backup or ipa-client-restore
> that you could run to generate/restore a gpg file with your clients
> info we could safely restore the config after disk had been wiped.
> Another possibly simpler option would be being able to reset the OTP
> without having to disable the host first, so the first time the IPA
> server sees a new ipa-client-install request with the right OTP it
> automatically disables the host server side then enrolls the client
> that made the request. (Or even simpler if there's any documentation
> on what files you would need to back up) 
>  
> I prefer option 2 :-)


I am trying to understand the sequence of the operations here.
You have a client that you need to periodically re-install or re-deploy it.

Before you re-install you need to set the OTP (because it is OTP)
anyways. This means you need some software to run a command against IPA.
OK so at that moment you can remove the host and then re-create it again
in IPA and set the OTP there.
On the client side you run ipa-client-install providing OTP and it
creates the host keytab and does all configuration steps.
After that you can log with any user account you have into that client
(unless you prohibited this user from logging in via HBAC).

It seems that what you are asking above is the ability to set OTP
without disabling the host...
Is the problem with sequencing? Are you saying that while the client is
still working you already need to prepare it for the next re-enrollment
without disrupting current operations?
I can understand that.
But what prevents you from doing operations in sequence: uninstall
client, recreate the host and OTP on the server side, re-install the client?



>  
> Thanks,
> Charlie
>
>
> On Tue, Sep 18, 2012 at 3:41 PM, Dmitri Pal  > wrote:
>
> On 09/18/2012 07:34 AM, Charlie Derwent wrote:
>> Hi
>>  
>> I've used "ipa host-disable ${HOST}; ipa host-mod
>> --password=${PASS} ${HOST}" In the past and that seems to work
>> quite well. The ideal for me would be a situation where the IPA
>> information could persist between rebuilds.
>
>
> Can you please elaborate more?
> Between rebuilds of what client or server?
> And what information you want to persist: cert, keytab, OTP?
>
> Thanks
> Dmitri
>
>
>>  
>> Cheers,
>> Charlie
>> On Tue, Sep 18, 2012 at 12:05 PM, Innes, Duncan
>> > > wrote:
>>
>> Folks,
>>
>> Juggling a problem here that perhaps doesn't have a perfect
>> solution.
>> I'm looking at systems that get re-provisioned by a
>> Satellite/Spacewalk/Installation method.  For full (Free)IPA
>> integration, we normally delete the old entry from IPA,
>> create a new one
>> from scratch and set the OTP to match what we put in our
>> post-install
>> script called by the kickstart file.
>>
>> Just noticed that I can do the same thing by Unprovisioning
>> the system
>> via the WebUI and then setting the OTP.
>>
>> Is there a way to Unprovision a registered host and set a OTP
>> via the
>> command line?  I was looking at 'ipa host-mod --setattr' but
>> not getting
>> too far with the Unprovisioning aspect.
>>
>> Duncan Innes | Linux Architect | Virgin Money | +44 1603
>> 215476  | +44
>> 7801 134507 | duncan.in...@virginmoney.com
>> 
>>
>>
>>
>> > -Original Message-
>> > From: freeipa-users-boun...@redhat.com
>> 
>> > [mailto:freeipa-users-boun...@redhat.com
>> ] On Behalf Of JR Aquino
>> > Sent: 18 September 2012 03:58
>> > To: Tim Hildred
>> > Cc: freeipa-users
>> > Subject: Re: [Freeipa-users] Password requirements too
>> stringent
>> >
>> >
>> > On Sep 17, 2012, at 7:53 PM, Tim Hildred wrote:
>> >
>> > > JR
>> > >
>> > > I had that line. I commented it out. Thank you.
>> > >
>>

Re: [Freeipa-users] Certificate serial number not found error

[Rob Crittenden]

James Hogarth wrote:

Hi,

When trying to view a particular service (or the related host) I'm
getting the following error in the UI:

IPA Error 4301
Certificate operation cannot be completed: EXCEPTION (Certificate serial
number 0xffe000c not found)

Now I've seen similar issue in the past when replication has played up
and then using ipa-csmanage-replica and forcing syncs (or finding the
system the certificate is registered on and deleting it there) has
cleared it up...

Unfortunately I suspect this was on an old replica which no longer
exists given the error occurs on either of the pair I now have for this
host and service...

Given there's no 'ignore warning and remove what you can' so far as I
can see I suspect I'm going to have to delve into LDAP to unravel the
mess but does anyone know the relevant areas in both 389 servers to do
this as safely as possible and reduce the risk in doing so as much as
possible?


You can use ldapmodify to remove the userCertificate attribute from the 
host.


# kinit admin
# ldapmodify -Y GSSAPI
SASL/GSSAPI authentication started
SASL username: ad...@example.com
SASL SSF: 56
SASL data security layer installed.
dn: fqdn=pacer.example.com,cn=computers,cn=accounts,dc=example,dc=com
changetype: modify
delete: usercertificate

modifying entry 
"fqdn=pacer.example.com,cn=computers,cn=accounts,dc=example,dc=com"


You'll probably want to delete the certificate out of /etc/pki/nssdb on 
the host too.


rob

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] how to allow a remote realm user to be an IPA admin?

[Alexander Bokovoy]

On Sun, 09 Dec 2012, Brian Cook wrote:

How do you let a remote user be an admin for IPA?

You cannot do it, at least right now.



I followed the fedora group example

external group:ad_admins_external
Posix Group: ad_admins

Then I made ad_admins a group member of ipa group 'admins' -
theoretically now MSAD\Administrator is an IPA admin?  I get the
following.  How does this work?


Being able to perform IPA management operations means being able to bind
to IPA LDAP with the identity in question. For Kerberos authentication
LDAP server maps user principal to a DN of an object in LDAP.

In case of trust users there are no LDAP objects that they represent
since the whole idea of a trust was to avoid replicating objects between
the realms, so while IPA KDC accepts AD realm's tickets for the users,
IPA LDAP server doesn't know what they map to in terms of LDAP objects.

Thus, trust users cannot be used to bind for LDAP access.


sh-4.1$ ipa user-add
ipa: ERROR: Could not create log_dir u'/home/msad.test/administrator/.ipa/log'
First name: joe
Last name: blo
User login [jblo]:
ipa: ERROR: Insufficient access: SASL(-14): authorization failure: Invalid 
credentials

At this step IPA server code you are talking to attempts to bind to LDAP server
on your (administra...@msad.test) behalf. LDAP server cannot map
administra...@msad.test to an existing DN, thus a failure is raised.

Since access controls in 389-ds LDAP server are built around DNs of
existing objects, you need to be able to map these ephemeral users to
some existing objects first to allow them to bind to LDAP. We haven't
done that yet but may at some point in future consider adding sort of
ephemeral bind support. It is unclear how to do it properly, considering
all security implications.

--
/ Alexander Bokovoy

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] cross realm trust - SID doesn't resolve

[Alexander Bokovoy]

On Sun, 09 Dec 2012, Brian Cook wrote:

Good to know my setup is working, but for administration purposes
displaying a SID in the GUI is as useless as displaying UID's with no
user name.  SID's are not meant for human eyes.  Is there some issue
with resolving it to the name and displaying the name instead?  Should
I open an RFE?

Since resolving SID means contacting AD's global catalog, there might be
delays and even failure. I'll see how we can do it in a safe way.

Please add an RFE.

--
/ Alexander Bokovoy

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users