Re: [Freeipa-users] server 1 and server 2 cannot replicate now may be ssl cert expire

[barrykfl]

Do u meant the error related to OS?
2016年5月9日 下午7:17 於 "Lukas Slebodnik"  寫道：

> On (09/05/16 12:14), Barry wrote:
> >  Hello Barry,
> >
> >Can you provide more info?
> >
> >What is your IPA version, OS?
> >
> >CENTOS 6.5
> >
> Please upgrade to latest CentOS 6.7
> there are known bugs in CentOS 6.5
> which are already fixed in CentOS 6.7.
>
> 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] freeipa as organizational CA

[Fraser Tweedale]

On Mon, May 09, 2016 at 10:23:07PM +0300, Alexander Bokovoy wrote:
> On Mon, 09 May 2016, Andy Thompson wrote:
> >Is freeipa in RHEL7.2 able to be used as an organizational CA these
> >days?  I have a requirement to set one up and like the IPA interface
> >and tools, but can't sort out the current state in 4.2 to decipher
> >whether this is possible, or even reasonable to try.  I need to setup
> >an org sub CA with an offline root CA
> Sub-CA support is coming in FreeIPA 4.4, hopefully. Current code in RHEL
> 7.2 does not support sub-CA functionality.
> 
Andy, you can install FreeIPA as a sub-CA of your offline root.
Support for creating sub-CAs *within* FreeIPA, under the "main"
FreeIPA CA (which in your case is a sub-CA of your offline root), is
not yet available but I am working on that.  But if you only need
one CA as a sub-CA of an offline root, you can use FreeIPA today.

> >The dogtag pki-ca in 7.2 appears to be missing some pieces, none of the
> >management themes seem to be available and the console utilities are
> >hit and miss, so I'm looking at this possibility.  Seems like overkill
> >but thought I'd toss the idea around.
> I think RHCS is a separate product with support on top of RHEL 7. Check
> with your Red Hat representatives.
> -- 
> / 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

-- 
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] freeipa as organizational CA

[Alexander Bokovoy]

On Mon, 09 May 2016, Andy Thompson wrote:

-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com]
Sent: Monday, May 9, 2016 3:23 PM
To: Andy Thompson 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] freeipa as organizational CA

On Mon, 09 May 2016, Andy Thompson wrote:
>Is freeipa in RHEL7.2 able to be used as an organizational CA these
>days?  I have a requirement to set one up and like the IPA interface
>and tools, but can't sort out the current state in 4.2 to decipher
>whether this is possible, or even reasonable to try.  I need to setup
>an org sub CA with an offline root CA
Sub-CA support is coming in FreeIPA 4.4, hopefully. Current code in RHEL
7.2 does not support sub-CA functionality.



If I can get an exclusion for the sub-CA bits, can that be added at a
later time and just run with a root CA for now?  Can it perform all of
the needs of an org CA outside of an IPA environment?

Not through the IPA interfaces but standard Dogtag is there, with its
(albeit a bit cumbersome) web UI. So I guess you could do what IPA
doesn't allow via that one, though there will be no support for these
functions.

When FreeIPA will get sub-CA support added, an upgrade path should be
there to allow creating sub-CAs.
--
/ Alexander Bokovoy

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

Re: [Freeipa-users] freeipa as organizational CA

[Alexander Bokovoy]

On Mon, 09 May 2016, Andy Thompson wrote:

Is freeipa in RHEL7.2 able to be used as an organizational CA these
days?  I have a requirement to set one up and like the IPA interface
and tools, but can't sort out the current state in 4.2 to decipher
whether this is possible, or even reasonable to try.  I need to setup
an org sub CA with an offline root CA

Sub-CA support is coming in FreeIPA 4.4, hopefully. Current code in RHEL
7.2 does not support sub-CA functionality.


The dogtag pki-ca in 7.2 appears to be missing some pieces, none of the
management themes seem to be available and the console utilities are
hit and miss, so I'm looking at this possibility.  Seems like overkill
but thought I'd toss the idea around.

I think RHCS is a separate product with support on top of RHEL 7. Check
with your Red Hat representatives.
--
/ Alexander Bokovoy

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

Re: [Freeipa-users] Correct way to install plugins?

[Rob Crittenden]

Jeffery Harrell wrote:

Thanks very much, Rob. Would it be best to install the schema file in
…/updates so it lives there permanently, or is it enough to just run it
through ipa-ldap-updater the one time? I’m sorry if that’s a dumb
question; I’ve only been working with IPA for a couple weeks so I’m
still working on building my intuition for it.


What I would recommend is packaging the whole thing as an rpm. Then you 
can be sure that the same bits are installed on every master and as 
changes are needed you can roll them out in a controlled way. And rpm -V 
will tell you if there are any local customizations.


This would involve putting the update files into .../updates. I don't 
believe there is any downside in putting files there.


rob



I’d be happy to share my DHCP plugin, but it’s pretty sketchy. ISC
DHCPd’s LDAP support is kind of idiosyncratic, so my plugin is pretty
purpose-built for our environment and needs. It might be a starting
point for somebody else, though. I’ll put the polish on the code and
share a Github link later today or maybe tomorrow.

Thanks again for the advice.

On May 9, 2016 at 11:45:25 AM, Rob Crittenden (rcrit...@redhat.com
) wrote:


Jeffery Harrell wrote:
> Good morning. (It’s morning where I am.)
>
> I’ve written several plugins for my deployment, including a DHCP plugin,
> and I’m trying to figure out the best way to deploy them onto production
> servers.
>
> Let’s start with the schema. I could copy a schema file (e.g.,
> 89dhcp.ldif and others) into /etc/dirsrv/slapd-REALM/schema and do a
> schema reload, or I could use ldapmodify to write the schema directly
> into the running system so it gets written into
> /etc/dirsrv/slapd-REALM/schema/99user.ldif.
>
> Is there any reason to prefer one over the other? Doing it the first way
> seems more tidy to me, but it has to be done on each server separately,
> which makes me wonder if it might cause things to get weird with respect
> to replication during that short span of time when one server has the
> schema and the other doesn’t. The Red Hat Directory Server documentation
> stops short of saying that local schemata should always be installed
> with ldapmodify into 99user.ldif, but it seems to kind of head-fake in
> that direction, so I’m not sure what the right method is.

The answer is neither: you want to use ipa-ldap-updater
--schema-file=

You definitely want to do it online so the schema gets replicated (and
into 99user.ldif) so entries on non-updated masters don't blow up.

> Then there are the update files. For the DHCP plugin, for instance, I
> have a short update file that initializes a few objects (see below). Is
> it better to just RUN this update against a live server with
> ipa-ldap-updater, or is it better to INSTALL this file
> in /usr/share/ipa/updates so it stays on the server permanently? Will
> the second approach be better in case of upgrades or whatever?

I'd install it into /usr/share/ipa/updates. The updater is more or less
idempotent so it shouldn't hurt anything to run it multiple times.

Once you have things working you might consider submitting your work
upstream. There is a long-standing ticket for DHCP integration,
https://fedorahosted.org/freeipa/ticket/939

rob

> Thanks very much for taking the time. I hope my questions made sense.
>
> Jeffery
>
> DHCP update file for reference, if necessary:
>
> dn: cn=dhcp,$SUFFIX
> add: objectClass: top
> add: objectClass: dhcpService
> add: dhcpStatements: authoritative
> add: dhcpStatements: default-lease-time 43200
> add: dhcpStatements: max-lease-time 86400
> add: dhcpStatements: one-lease-per-client on
>
> dn: cn=dhcpHosts,cn=Schema Compatibility,cn=plugins,cn=config
> add: objectClass: top
> add: objectClass: extensibleObject
> add: schema-compat-container-group: cn=hosts,cn=dhcp,$SUFFIX
> add: schema-compat-search-base: cn=computers,cn=accounts,$SUFFIX
> add: schema-compat-search-filter:
> (&(macAddress=*)(fqdn=*)(objectClass=ipaHost))
> add: schema-compat-entry-rdn: cn=%{fqdn}
> add: schema-compat-entry-attribute: objectClass=dhcpHost
> add: schema-compat-entry-attribute: dhcpHWAddress=ethernet %{macAddress}
> add: schema-compat-entry-attribute: dhcpStatements=fixed-address %{fqdn}
> add: schema-compat-entry-attribute: dhcpOption=host-name "%{fqdn}"
>
> dn: cn=DHCP Administrators,cn=privileges,cn=pbac,$SUFFIX
> add: objectClass: top
> add: objectClass: groupofnames
> add: objectClass: nestedgroup
> only: description: DHCP Administrators
>
> plugin: update_managed_permissions
>
>
>



--
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] freeipa as organizational CA

[Andy Thompson]

Is freeipa in RHEL7.2 able to be used as an organizational CA these days?  I 
have a requirement to set one up and like the IPA interface and tools, but 
can't sort out the current state in 4.2 to decipher whether this is possible, 
or even reasonable to try.  I need to setup an org sub CA with an offline root 
CA

The dogtag pki-ca in 7.2 appears to be missing some pieces, none of the 
management themes seem to be available and the console utilities are hit and 
miss, so I'm looking at this possibility.  Seems like overkill but thought I'd 
toss the idea around.

Thanks!

-andy


*** This communication may contain privileged and/or confidential information. 
It is intended solely for the use of the addressee. If you are not the intended 
recipient, you are strictly prohibited from disclosing, copying, distributing 
or using any of this information. If you received this communication in error, 
please contact the sender immediately and destroy the material in its entirety, 
whether electronic or hard copy. ***


-- 
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] Correct way to install plugins?

[Jeffery Harrell]

Thanks very much, Rob. Would it be best to install the schema file in …/updates 
so it lives there permanently, or is it enough to just run it through 
ipa-ldap-updater the one time? I’m sorry if that’s a dumb question; I’ve only 
been working with IPA for a couple weeks so I’m still working on building my 
intuition for it.

I’d be happy to share my DHCP plugin, but it’s pretty sketchy. ISC DHCPd’s LDAP 
support is kind of idiosyncratic, so my plugin is pretty purpose-built for our 
environment and needs. It might be a starting point for somebody else, though. 
I’ll put the polish on the code and share a Github link later today or maybe 
tomorrow.

Thanks again for the advice.

On May 9, 2016 at 11:45:25 AM, Rob Crittenden (rcrit...@redhat.com) wrote:

Jeffery Harrell wrote:  
> Good morning. (It’s morning where I am.)  
>  
> I’ve written several plugins for my deployment, including a DHCP plugin,  
> and I’m trying to figure out the best way to deploy them onto production  
> servers.  
>  
> Let’s start with the schema. I could copy a schema file (e.g.,  
> 89dhcp.ldif and others) into /etc/dirsrv/slapd-REALM/schema and do a  
> schema reload, or I could use ldapmodify to write the schema directly  
> into the running system so it gets written into  
> /etc/dirsrv/slapd-REALM/schema/99user.ldif.  
>  
> Is there any reason to prefer one over the other? Doing it the first way  
> seems more tidy to me, but it has to be done on each server separately,  
> which makes me wonder if it might cause things to get weird with respect  
> to replication during that short span of time when one server has the  
> schema and the other doesn’t. The Red Hat Directory Server documentation  
> stops short of saying that local schemata should always be installed  
> with ldapmodify into 99user.ldif, but it seems to kind of head-fake in  
> that direction, so I’m not sure what the right method is.  

The answer is neither: you want to use ipa-ldap-updater  
--schema-file=  

You definitely want to do it online so the schema gets replicated (and  
into 99user.ldif) so entries on non-updated masters don't blow up.  

> Then there are the update files. For the DHCP plugin, for instance, I  
> have a short update file that initializes a few objects (see below). Is  
> it better to just RUN this update against a live server with  
> ipa-ldap-updater, or is it better to INSTALL this file  
> in /usr/share/ipa/updates so it stays on the server permanently? Will  
> the second approach be better in case of upgrades or whatever?  

I'd install it into /usr/share/ipa/updates. The updater is more or less  
idempotent so it shouldn't hurt anything to run it multiple times.  

Once you have things working you might consider submitting your work  
upstream. There is a long-standing ticket for DHCP integration,  
https://fedorahosted.org/freeipa/ticket/939  

rob  

> Thanks very much for taking the time. I hope my questions made sense.  
>  
> Jeffery  
>  
> DHCP update file for reference, if necessary:  
>  
> dn: cn=dhcp,$SUFFIX  
> add: objectClass: top  
> add: objectClass: dhcpService  
> add: dhcpStatements: authoritative  
> add: dhcpStatements: default-lease-time 43200  
> add: dhcpStatements: max-lease-time 86400  
> add: dhcpStatements: one-lease-per-client on  
>  
> dn: cn=dhcpHosts,cn=Schema Compatibility,cn=plugins,cn=config  
> add: objectClass: top  
> add: objectClass: extensibleObject  
> add: schema-compat-container-group: cn=hosts,cn=dhcp,$SUFFIX  
> add: schema-compat-search-base: cn=computers,cn=accounts,$SUFFIX  
> add: schema-compat-search-filter:  
> (&(macAddress=*)(fqdn=*)(objectClass=ipaHost))  
> add: schema-compat-entry-rdn: cn=%{fqdn}  
> add: schema-compat-entry-attribute: objectClass=dhcpHost  
> add: schema-compat-entry-attribute: dhcpHWAddress=ethernet %{macAddress}  
> add: schema-compat-entry-attribute: dhcpStatements=fixed-address %{fqdn}  
> add: schema-compat-entry-attribute: dhcpOption=host-name "%{fqdn}"  
>  
> dn: cn=DHCP Administrators,cn=privileges,cn=pbac,$SUFFIX  
> add: objectClass: top  
> add: objectClass: groupofnames  
> add: objectClass: nestedgroup  
> only: description: DHCP Administrators  
>  
> plugin: update_managed_permissions  
>  
>  
>  

-- 
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] Correct way to install plugins?

[Rob Crittenden]

Jeffery Harrell wrote:

Good morning. (It’s morning where I am.)

I’ve written several plugins for my deployment, including a DHCP plugin,
and I’m trying to figure out the best way to deploy them onto production
servers.

Let’s start with the schema. I could copy a schema file (e.g.,
89dhcp.ldif and others) into /etc/dirsrv/slapd-REALM/schema and do a
schema reload, or I could use ldapmodify to write the schema directly
into the running system so it gets written into
/etc/dirsrv/slapd-REALM/schema/99user.ldif.

Is there any reason to prefer one over the other? Doing it the first way
seems more tidy to me, but it has to be done on each server separately,
which makes me wonder if it might cause things to get weird with respect
to replication during that short span of time when one server has the
schema and the other doesn’t. The Red Hat Directory Server documentation
stops short of saying that local schemata should always be installed
with ldapmodify into 99user.ldif, but it seems to kind of head-fake in
that direction, so I’m not sure what the right method is.


The answer is neither: you want to use ipa-ldap-updater 
--schema-file=


You definitely want to do it online so the schema gets replicated (and 
into 99user.ldif) so entries on non-updated masters don't blow up.



Then there are the update files. For the DHCP plugin, for instance, I
have a short update file that initializes a few objects (see below). Is
it better to just RUN this update against a live server with
ipa-ldap-updater, or is it better to INSTALL this file
in /usr/share/ipa/updates so it stays on the server permanently? Will
the second approach be better in case of upgrades or whatever?


I'd install it into /usr/share/ipa/updates. The updater is more or less 
idempotent so it shouldn't hurt anything to run it multiple times.


Once you have things working you might consider submitting your work 
upstream. There is a long-standing ticket for DHCP integration, 
https://fedorahosted.org/freeipa/ticket/939


rob


Thanks very much for taking the time. I hope my questions made sense.

Jeffery

DHCP update file for reference, if necessary:

dn: cn=dhcp,$SUFFIX
add: objectClass: top
add: objectClass: dhcpService
add: dhcpStatements: authoritative
add: dhcpStatements: default-lease-time 43200
add: dhcpStatements: max-lease-time 86400
add: dhcpStatements: one-lease-per-client on

dn: cn=dhcpHosts,cn=Schema Compatibility,cn=plugins,cn=config
add: objectClass: top
add: objectClass: extensibleObject
add: schema-compat-container-group: cn=hosts,cn=dhcp,$SUFFIX
add: schema-compat-search-base: cn=computers,cn=accounts,$SUFFIX
add: schema-compat-search-filter:
(&(macAddress=*)(fqdn=*)(objectClass=ipaHost))
add: schema-compat-entry-rdn: cn=%{fqdn}
add: schema-compat-entry-attribute: objectClass=dhcpHost
add: schema-compat-entry-attribute: dhcpHWAddress=ethernet %{macAddress}
add: schema-compat-entry-attribute: dhcpStatements=fixed-address %{fqdn}
add: schema-compat-entry-attribute: dhcpOption=host-name "%{fqdn}"

dn: cn=DHCP Administrators,cn=privileges,cn=pbac,$SUFFIX
add: objectClass: top
add: objectClass: groupofnames
add: objectClass: nestedgroup
only: description: DHCP Administrators

plugin: update_managed_permissions





--
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] export/import users password between two differents IPA environment

[Rob Crittenden]

Alexandre Ellert wrote:

Hello,

I have a broken IPA environnment with very few users and groups and
I've setup a fresh new installation.
I already recreate users and groups and now need to keep old users
passwords. Is there a way to copy/paste users password between these
two differents IPA ?


If you had done a migration from the old to new IPA then the passwords 
would have come along. The problem you're going to have is that 
pre-hashed passwords are only allowed when adding an entry. To be able 
to do that you'll need to add some user to passSyncManagersDNs and bind 
as that user when loading the passwords (you can pull them from the old 
server by binding as Directory Manager).


You almost certainly will want to remove the user in passSyncManagersDNs 
once finished.


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] Correct way to install plugins?

[Jeffery Harrell]

Good morning. (It’s morning where I am.)

I’ve written several plugins for my deployment, including a DHCP plugin, and 
I’m trying to figure out the best way to deploy them onto production servers.

Let’s start with the schema. I could copy a schema file (e.g., 89dhcp.ldif and 
others) into /etc/dirsrv/slapd-REALM/schema and do a schema reload, or I could 
use ldapmodify to write the schema directly into the running system so it gets 
written into /etc/dirsrv/slapd-REALM/schema/99user.ldif.

Is there any reason to prefer one over the other? Doing it the first way seems 
more tidy to me, but it has to be done on each server separately, which makes 
me wonder if it might cause things to get weird with respect to replication 
during that short span of time when one server has the schema and the other 
doesn’t. The Red Hat Directory Server documentation stops short of saying that 
local schemata should always be installed with ldapmodify into 99user.ldif, but 
it seems to kind of head-fake in that direction, so I’m not sure what the right 
method is.

Then there are the update files. For the DHCP plugin, for instance, I have a 
short update file that initializes a few objects (see below). Is it better to 
just RUN this update against a live server with ipa-ldap-updater, or is it 
better to INSTALL this file in /usr/share/ipa/updates so it stays on the server 
permanently? Will the second approach be better in case of upgrades or whatever?

Thanks very much for taking the time. I hope my questions made sense.

Jeffery

DHCP update file for reference, if necessary:

dn: cn=dhcp,$SUFFIX
add: objectClass: top
add: objectClass: dhcpService
add: dhcpStatements: authoritative
add: dhcpStatements: default-lease-time 43200
add: dhcpStatements: max-lease-time 86400
add: dhcpStatements: one-lease-per-client on

dn: cn=dhcpHosts,cn=Schema Compatibility,cn=plugins,cn=config
add: objectClass: top
add: objectClass: extensibleObject
add: schema-compat-container-group: cn=hosts,cn=dhcp,$SUFFIX
add: schema-compat-search-base: cn=computers,cn=accounts,$SUFFIX
add: schema-compat-search-filter: (&(macAddress=*)(fqdn=*)(objectClass=ipaHost))
add: schema-compat-entry-rdn: cn=%{fqdn}
add: schema-compat-entry-attribute: objectClass=dhcpHost
add: schema-compat-entry-attribute: dhcpHWAddress=ethernet %{macAddress}
add: schema-compat-entry-attribute: dhcpStatements=fixed-address %{fqdn}
add: schema-compat-entry-attribute: dhcpOption=host-name "%{fqdn}"

dn: cn=DHCP Administrators,cn=privileges,cn=pbac,$SUFFIX
add: objectClass: top
add: objectClass: groupofnames
add: objectClass: nestedgroup
only: description: DHCP Administrators

plugin: update_managed_permissions

-- 
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-replica-install fails at [6/8]: enable GSSAPI for replication

[Devin Acosta]

Attempting to create replica fails during ipa-replica-install. I have 
attached below what I am seeing during attempting to add a replica into 
my environment. Currently there are (3) Masters. When I try to add the 
(4th) it dies. The 4th node will only be able to talk to ipa01-aws, 
ipa02-aws, it will not be able to talk to ipa1-i2x, will that create a 
problem? I generated the replica from the ipa01-aws instance.


ipa02-aws.rsinc.local: master
ipa01-aws.rsinc.local: master
ipa1-i2x.rsinc.local: master

[root@idm1-dev centos]# ipa-replica-install --setup-dns 
--forwarder=8.8.8.8 --mkhomedir replica-info-idm1-dev.rsinc.local.gpg

WARNING: conflicting time synchronization service 'chronyd' will
be disabled in favor of ntpd

Directory Manager (existing master) password:

Existing BIND configuration detected, overwrite? [no]: yes
Checking DNS forwarders, please wait ...
Using reverse zone(s) 0.31.10.in-addr.arpa.
Run connection check to master
Check connection from replica to remote master 'ipa01-aws.rsinc.local':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

The following list of ports use UDP protocol and would need to be
checked manually:
   Kerberos KDC: UDP (88): SKIPPED
   Kerberos Kpasswd: UDP (464): SKIPPED

Connection from replica to master is OK.
Start listening on required ports for remote master check
Get credentials to log in to remote master
admin@RSINC.LOCAL password:

Check SSH connection to remote master
Execute check on remote master
Check connection from master to remote replica 'idm1-dev.rsinc.local':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos KDC: UDP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   Kerberos Kpasswd: UDP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

Connection from master to replica is OK.

Connection check OK
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/38]: creating directory server user
  [2/38]: creating directory server instance
  [3/38]: adding default schema
  [4/38]: enabling memberof plugin
  [5/38]: enabling winsync plugin
  [6/38]: configuring replication version plugin
  [7/38]: enabling IPA enrollment plugin
  [8/38]: enabling ldapi
  [9/38]: configuring uniqueness plugin
  [10/38]: configuring uuid plugin
  [11/38]: configuring modrdn plugin
  [12/38]: configuring DNS plugin
  [13/38]: enabling entryUSN plugin
  [14/38]: configuring lockout plugin
  [15/38]: creating indices
  [16/38]: enabling referential integrity plugin
  [17/38]: configuring ssl for ds instance
  [18/38]: configuring certmap.conf
  [19/38]: configure autobind for root
  [20/38]: configure new location for managed entries
  [21/38]: configure dirsrv ccache
  [22/38]: enable SASL mapping fallback
  [23/38]: restarting directory server
  [24/38]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 4 seconds elapsed
Update succeeded

  [25/38]: updating schema
  [26/38]: setting Auto Member configuration
  [27/38]: enabling S4U2Proxy delegation
  [28/38]: importing CA certificates from LDAP
  [29/38]: initializing group membership
  [30/38]: adding master entry
  [31/38]: initializing domain level
  [32/38]: configuring Posix uid/gid generation
  [33/38]: adding replication acis
  [34/38]: enabling compatibility plugin
  [35/38]: activating sidgen plugin
  [36/38]: activating extdom plugin
  [37/38]: tuning directory server
  [38/38]: configuring directory to start on boot
Done configuring directory server (dirsrv).
Configuring Kerberos KDC (krb5kdc). Estimated time: 30 seconds
  [1/8]: adding sasl mappings to the directory
  [2/8]: configuring KDC
  [3/8]: creating a keytab for the directory
  [4/8]: creating a keytab for the machine
  [5/8]: adding the password extension to the directory
  [6/8]: enable GSSAPI for replication
  [error] RuntimeError: One of the ldap service principals is missing. 
Replication agreement cannot be converted.

Replication error message: Can't acquire busy replica
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(Replica): ERROROne of the 
ldap service principals is missing. Replication agreement cannot be 
converted.

Replication error message: Can't acquire busy replica



2016-05-09T02:45:27Z DEBUG Backing up system configuration file 
'/etc/krb5.keytab'
2016-05-09T02:45:27Z DEBUG Saving Index File to 
'/var/lib/ipa/sysrestore/sysrestore.index'

2016-05-09T02:45:27Z DEBUG Starting external 

[Freeipa-users] export/import users password between two differents IPA environment

[Alexandre Ellert]

Hello,

I have a broken IPA environnment with very few users and groups and
I've setup a fresh new installation.
I already recreate users and groups and now need to keep old users
passwords. Is there a way to copy/paste users password between these
two differents IPA ?

Thank you for your help

Alexandre

-- 
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] server 1 and server 2 cannot replicate now may be ssl cert expire

[Lukas Slebodnik]

On (09/05/16 12:14), Barry wrote:
>  Hello Barry,
>
>Can you provide more info?
>
>What is your IPA version, OS?
>
>CENTOS 6.5
>
Please upgrade to latest CentOS 6.7
there are known bugs in CentOS 6.5
which are already fixed in CentOS 6.7.

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] Who uses FreeIPA?

[Alexander Bokovoy]

On Mon, 09 May 2016, Martin Basti wrote:



On 09.05.2016 00:48, Alexandre de Verteuil wrote:

* Alexandre de Verteuil  [2016-05-03 15:09] :

Tomorrow I am giving a short presentation at my workplace to talk about
it and invite other sysadmins to try it.

I would like to make a slide showing the current adoption of FreeIPA. I
read that Red Hat uses it internally, but do they actually deploy it in
their client's infrastructures? Are there any big companies that use it?
Even if I only have reports of schools and small businesses would be
good enough to say it's production ready and it has traction.

Hello all,

Thank you very much for your input. I do encourage you to write a page of
success stories, or at least mention that it is being used in small to
large scale production sites. Who uses FreeIPA is one of the first
questions I am asked when I talk about it.

I did my presentation as promised and I received good feedback and
people mentioned they were interested in trying it and learning more. I
have also repeated the presentation last friday at a smaller scale and
this time I have filmed it.

https://www.youtube.com/watch?v=JrgIpwptxWk

Best regards,


Nice video!

Please note that docs on fedorahosted are really outdated, please use 
rather official Red Hat IdM guides


https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/index.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/index.html

Also a nit-pick: LDAP is '90ies, not '80ies. First LDAP version is dated
1993, while LDAPv3 as used nowadays came out in 1997. Even X.500 series
of standards which conceptually define a store LDAP supposed to access,
were first approved in 1988.

--
/ Alexander Bokovoy

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

Re: [Freeipa-users] Who uses FreeIPA?

[Martin Basti]

On 09.05.2016 00:48, Alexandre de Verteuil wrote:

* Alexandre de Verteuil  [2016-05-03 15:09] :

Tomorrow I am giving a short presentation at my workplace to talk about
it and invite other sysadmins to try it.

I would like to make a slide showing the current adoption of FreeIPA. I
read that Red Hat uses it internally, but do they actually deploy it in
their client's infrastructures? Are there any big companies that use it?
Even if I only have reports of schools and small businesses would be
good enough to say it's production ready and it has traction.

Hello all,

Thank you very much for your input. I do encourage you to write a page of
success stories, or at least mention that it is being used in small to
large scale production sites. Who uses FreeIPA is one of the first
questions I am asked when I talk about it.

I did my presentation as promised and I received good feedback and
people mentioned they were interested in trying it and learning more. I
have also repeated the presentation last friday at a smaller scale and
this time I have filmed it.

https://www.youtube.com/watch?v=JrgIpwptxWk

Best regards,


Nice video!

Please note that docs on fedorahosted are really outdated, please use 
rather official Red Hat IdM guides


https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/index.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/index.html

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] Duplicate serials in issued ipa certs

[wouter.hummelink]

All 4 of our  ipa servers are RHEL7.2 with IPA 4.2.
Last august the original  CA master was damaged so I moved the CRL role to 
another server, 
decommissioned the machine and deleted all the replication agreements and 
rebuilt the machine.

That machine now appears to have issued the certs that have duplicated serials.
My immediate problem now is however that I can't deprovision the machine that 
one of these certs was issued for, nor can I revoke the certs.

What would be the proper way to remove these certs from ldap?

-Oorspronkelijk bericht-
Van: Fraser Tweedale [mailto:ftwee...@redhat.com] 
Verzonden: maandag 9 mei 2016 01:10
Aan: Hummelink, Wouter
CC: freeipa-users@redhat.com
Onderwerp: Re: [Freeipa-users] Duplicate serials in issued ipa certs

On Fri, May 06, 2016 at 11:33:10AM +, wouter.hummel...@kpn.com wrote:
> Hello,
> 
> I discovered today that our IPA CA has been issuing certs with 
> duplicate serials, causing issues in several ways when dealing with 
> hosts that have such a cert in place. (Complaints about duplicate serials) 
> Removing the offending cert from the host results in de same type of error 
> These all seem to have been issued from the server that in the past was 
> reinstalled with the same hostname.
> 
Can you please describe the history of the server in more detail?
(i.e. what do you mean by "was reinstalled" - including whether it was a 
replica, etc).  Also, which FreeIPA version(s) are you using?

Thanks,
Fraser

> ipa host-show app
> ipa: ERROR: Certificate format error: (SEC_ERROR_REUSED_ISSUER_AND_SERIAL) 
> You are attempting to import a cert with the same issuer/serial as an 
> existing cert, but that is not the same cert.
> 
> IPA cert-find indeed shows 2 issued certs with the same serial 
> (several actually)
> 
> (anonymized)
> Serial number (hex): 0xFFF0007
>   Serial number: 268369927
>   Status: VALID
>   Subject: CN=app.example.org,O=EXAMPLE.ORG
> 
>   Serial number (hex): 0xFFF0007
>   Serial number: 268369927
>   Status: VALID
>   Subject: CN=ipa.example.org,O=EXAMPLE.ORG
> 
> The ipa client won't let me revoke or otherwise kill these certs with the 
> same error.
> What to do?
> 
> Met vriendelijke groet,
> 
> Wouter Hummelink
> Cloud Engineer
> [Description: Beschrijving: Beschrijving: 
> cid:image003.gif@01CC7CE9.FCFEC140]
> KPN IT Solutions
> Platform Organisation Cloud Services
> Mail: wouter.hummel...@kpn.com
> Telefoon: +31 (0)6 1288 2447
> [cid:image002.png@01D0DA65.706AE4B0]
> P Save Paper - Do you really need to print this e-mail?
> **
> **
> * KPN IT SOLUTIONS is de 'handelsnaam' voor KPN Corporate 
> Market BV, Handelsregister 52959597 Amsterdam The information 
> transmitted is intended only for use by the addressee and may contain 
> confidential and/or privileged material.
> Any review, re-transmission, dissemination or other use of it, or the 
> taking of any action in reliance upon this information by persons 
> and/or entities other than the intended recipient is prohibited. If you 
> received this in error, please inform the sender and/or addressee immediately 
> and delete the material. Thank you.
> **
> **
> *
> 




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