Re: [Freeipa-users] FreeIPA and abfab?

[Alexander Bokovoy]

On Tue, 14 Jan 2014, Nordgren, Bryce L -FS wrote:

In my previous message, I asked about one-way trust with AD to provide
a means of "extending" our corporate AD with accounts for external
cooperators. I expect this is just a technical matter: either FreeIPA
supports it or not, and there's no conceptual obstacles. So, my
password is the same, and everyone else needs a new account. Not ideal,
but it's achievable fairly easily with existing tools.

But what I really really want is an identity provider for the edge of
the enterprise, where I live. My password is the same and external
users can also use their normal password. Essentially, I want a
software suite which interfaces between the enterprise environment
where everything is centrally managed, and a federated environment
where there are too many organizations to shake a stick at.

I've been reading about "Application Bridging for Federated Access
Beyond Web" (abfab). https://datatracker.ietf.org/wg/abfab/ It appears
to me that the draft architecture document and the recently published
RFCs (7055, 7056, 7057) defines a mechanism for enterprises to federate
and opens up  a whole new application space. The big question is,
should enterprise-centric management apps expand to include federation,
or will a whole new crop of solutions pop up? Or, more pointedly, could
this gap be filled by augmenting an enterprise's existing AD deployment
with a federation-aware FreeIPA? Has FreeIPA considered moving into
this space?

I can see several areas where a federation aware, AD compatible
solution could add value to an organization:

Use case 1: Synchronizing enterprise IDs with IDs exposed to the
federation. (Currently, we have "AD" credentials and SAML credentials,
and they are not synched. And our SAML IdP does not participate in a
federation.)

Use case 2:  Software can use SAML credentials for workstation logins
(if the workstations are on the "research net"); and allow only
internal users to use "internal services".

Use case 3: Software provides access to "internal + federated"
identities using LDAP, SAML, Kerberos, etc.


Food for thought. I know this isn't near term, but at this point, I'm
just curious if people are even thinking along these lines?

Yes, we do have plans on being able to bridge with SAML IdP. This work
is not yet available for production use but we certainly are looking
into making IPA identities available for consumption through
SAML-assertions.

--
/ Alexander Bokovoy

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

Re: [Freeipa-users] One way trusts

[Alexander Bokovoy]

Hi,

On Tue, 14 Jan 2014, Nordgren, Bryce L -FS wrote:

Hi Dimitri,


Just to be sure I understand.  You have internal users - they are in
AD. You have external users - they are in LDAP.  You merge two
directories and you want to replace this setup with IPA.


Yes.


It seems that to support your use case you would need to make the
external users be IPA users and make AD and IPA trust each other.


I think I concur about migrating my external users into IPA and making
IPA trust AD. I may be ignorant of some AD nuance, but I do not see why
AD needs to trust IPA. AD does not need to trust my LDAP clients
currently.

IPA needs to be able to look up users and groups in AD. To do so, it
uses Kerberos authentication against AD's Global Catalog services with
own credentials (per each IPA host). We are using cross-realm
Kerberos trust here, AD DC trusts cross-realm TGT issued by IPA KDC and
vice versa, so IPA hosts can bind as their own identity (host/...) to
AD.

Since we don't implement fully all services needed to grant privileges
beyond read-only in AD, these binds to AD Global Catalog become
read-only. They are still required. An alternative would have been to
always keep an account in AD for each IPA host that needs to query user
and group identities from AD. We decided to go with the cross-realm
Kerberos trust instead since it gives better way of privilege separation.
Cross-realm Kerberos trust is known as cross-forest domain trust in AD
speak since there are more protocol layers than Kerberos involved (SMB
protocol, in particular, is used to set up and verify trust
relationship).

Once we implement AD GC service, AD admins will be able to subject IPA
users/hosts to further limit their access to other AD services beyond
simple read-only access to AD LDAP and SMB services. As result, in
future more fine-grained privilege and security separation between AD
and IPA will be possible.




Also if external users do not authenticate using Kerberos (for example
they always use a special portal) then it does not matter what trust
is between AD and IPA because those users will not have kerberos
tickets that are leveraged in SSO in trust case.


I want to be able to point either an LDAP or a Kerberos client at IPA,
and have it authenticate my "enterprise" and "external" users for me.
I'm not going to tangle with SSO at the moment. Right now, we're just
establishing an identity store.

That is what provided by IPA's AD trusts. IPA machines can resolve
identities of the users and groups in AD and can authenticate those
users on logons, subject to HBAC policies.


IPA can trust AD. Formally it is a mutual trust but in reality IPA
does not have global catalog support for users in IPA to be able to
access the resources in AD.


In many of the tutorials/HOWTOs, I see that there is a requirement to
provide credentials having the permission to add a computer to the
domain, or being a member of an AD administration group. I'm a lowly
standard "User" in the AD. I don't know if that means I can add a
computer to the domain or not. I know I lack the ability to edit AD
entries that aren't mine, so I really need a solution that does not
require creating a trust relationship inside AD.

Both AD integration solutions we have (synchronization and cross-forest
domain trusts) assume having higher level access privileges at the time
integration is set up. I'm unaware of other mechanisms that would give
you the same flexibility and level of privilege separation between the
AD and IPA domains. Having a standard 'User' account in AD only entitles
you to join up to 10 machines in AD. These machine will become a part of
AD domain and are subject of their policies which are quite extended by
default. Cross-forest domain trusts, on the other hand, are subject to
inter-domain trust relationship policies which are better constrained.

One could try to fiddle with AD-joined machine accounts to represent IPA
hosts but it is very much uncharted territory since there will be no
integration whatsoever on any of IPA features (access controls to IPA
services, ID allocation, etc) and everything will need to be set up and
maintained manually, including periodical refreshes of the machine
accounts. In addition, Kerberos authentication will simply not work as
AD has certain assumption over DNS namespace mapping to Kerberos realms.



Is there a way for me to comment out the AD->IPA trust creation, or
would that break the IPA->AD trust?

The latter, since AD->IPA part of the trust is used to query AD users
and groups. In other words, it is used to provide the key resources
needed to operate IPA->AD trust part.


--
/ Alexander Bokovoy

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

[Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)

[Les Stott]

Been banging my head against the wall on this one for a few days, trying to get 
a workable configuration for HP ILO to authenticate via FreeIPA.

I have a standard rhel6 environment (64 bit 6.4) with freeipa server 
(ipa-3.0.0-37.el6).

The following works for me..

HP ILO4 Firmware 1.22
Default Directory Schema
Directory Server Address: fqdn_of_myfreeipaserver
Directory Server LDAP Port: 636
Directory User Context 1: cn=users,cn=accounts,dc=mydomain,dc=com
Directory Groups: cn=sys_admins,cn=groups,cn=accounts,dc=mydomain,dc=com

but only if I login with my full dn

Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com

The test settings button in the ILO works only with the full dn.

It doesn't work if I use the uid (less), or the cn (Les Stott).

I can then login to ILO with 
Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com

If I try to login with the cn, Les Stott I see an error in the logs...

[13/Jan/2014:22:36:29 -0500] ipalockout_postop - [file ipa_lockout.c, line 
473]: Failed to retrieve entry "CN=Les 
Stott,cn=users,cn=accounts,dc=mydomain,dc=com": 32

I've read a lot of things about getting this to work. Apparently there are 
issues with HP ILO requiring the username in cn format but its in uid format in 
freeipa. You should also be able to login with your cn, but that doesn't work.

I had a crack at trying Kerberos authentication as well, but it doesn't work 
and errors with "Additional Pre-authentication required".

Has anyone successfully been able to get HP ILO to work with FreeIPA such that 
you can login with just the username (i.e. "less") or the CN (i.e. "Les Stott")?

Are schema changes required?

Alternatively has anyone been able to get HP ILO to work with Kerberos auth to 
FreeIPA?

Any help would be greatly appreciated.

Regards,

Les


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

[Freeipa-users] FreeIPA and abfab?

[Nordgren, Bryce L -FS]

In my previous message, I asked about one-way trust with AD to provide a means 
of "extending" our corporate AD with accounts for external cooperators. I 
expect this is just a technical matter: either FreeIPA supports it or not, and 
there's no conceptual obstacles. So, my password is the same, and everyone else 
needs a new account. Not ideal, but it's achievable fairly easily with existing 
tools.

But what I really really want is an identity provider for the edge of the 
enterprise, where I live. My password is the same and external users can also 
use their normal password. Essentially, I want a software suite which 
interfaces between the enterprise environment where everything is centrally 
managed, and a federated environment where there are too many organizations to 
shake a stick at.

I've been reading about "Application Bridging for Federated Access Beyond Web" 
(abfab). https://datatracker.ietf.org/wg/abfab/ It appears to me that the draft 
architecture document and the recently published RFCs (7055, 7056, 7057) 
defines a mechanism for enterprises to federate and opens up  a whole new 
application space. The big question is, should enterprise-centric management 
apps expand to include federation, or will a whole new crop of solutions pop 
up? Or, more pointedly, could this gap be filled by augmenting an enterprise's 
existing AD deployment with a federation-aware FreeIPA? Has FreeIPA considered 
moving into this space?

I can see several areas where a federation aware, AD compatible solution could 
add value to an organization:

Use case 1: Synchronizing enterprise IDs with IDs exposed to the federation. 
(Currently, we have "AD" credentials and SAML credentials, and they are not 
synched. And our SAML IdP does not participate in a federation.)

Use case 2:  Software can use SAML credentials for workstation logins (if the 
workstations are on the "research net"); and allow only internal users to use 
"internal services".

Use case 3: Software provides access to "internal + federated" identities using 
LDAP, SAML, Kerberos, etc.


Food for thought. I know this isn't near term, but at this point, I'm just 
curious if people are even thinking along these lines?

Bryce




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] One way trusts

[Nordgren, Bryce L -FS]

Hi Dimitri,

>Just to be sure I understand.
>You have internal users - they are in AD. You have external users - they are 
>in LDAP.
>You merge two directories and you want to replace this setup with IPA.

Yes.

>It seems that to support your use case you would need to make the external 
>users be IPA users and make AD and IPA trust each other.

I think I concur about migrating my external users into IPA and making IPA 
trust AD. I may be ignorant of some AD nuance, but I do not see why AD needs to 
trust IPA. AD does not need to trust my LDAP clients currently.

>Also if external users do not authenticate using Kerberos (for example they 
>always use a special portal) then it does not matter what trust is between AD 
>and IPA because those users will not have kerberos tickets that are leveraged 
>in SSO in trust case.

I want to be able to point either an LDAP or a Kerberos client at IPA, and have 
it authenticate my "enterprise" and "external" users for me. I'm not going to 
tangle with SSO at the moment. Right now, we're just establishing an identity 
store.

>IPA can trust AD. Formally it is a mutual trust but in reality IPA does not 
>have global catalog support for users in IPA to be able to access the 
>resources in AD.

In many of the tutorials/HOWTOs, I see that there is a requirement to provide 
credentials having the permission to add a computer to the domain, or being a 
member of an AD administration group. I'm a lowly standard "User" in the AD. I 
don't know if that means I can add a computer to the domain or not. I know I 
lack the ability to edit AD entries that aren't mine, so I really need a 
solution that does not require creating a trust relationship inside AD.

Is there a way for me to comment out the AD->IPA trust creation, or would that 
break the IPA->AD trust?

Thanks much,
Bryce







This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.


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

Re: [Freeipa-users] One way trusts

[Dmitri Pal]

On 01/13/2014 06:29 PM, Nordgren, Bryce L -FS wrote:
>
> Hello,
>
>  
>
> I manage a suite of machines and services which are used for
> collaborative projects with external partners. I want to allow users
> within our organization to authenticate with their existing Active
> Directory accounts, and I have set up an "External Users" LDAP
> directory to establish identities for our partners. I have an LDAP
> server set up which merges the two directories and which forwards
> requests on to the correct directory.
>
>  
>
> I like the idea of FreeIPA, however, I need support for a one-way
> trust. I don't have the ability to modify any entries in our AD
> server, but I do have a normal user account (hence I can bind to AD's
> LDAP interface). However, I think this is kind of  a moot point since
> external users should under no circumstances be allowed access to our
> internal network/services. Read-only access to AD is just peachy. I
> found this old message (June 2012) on your mailing list which suggests
> one-way trusts may be on your radar. [1] However, I looked through
> your Trac tickets and didn't see any follow up. Did I miss something?
> Is this already implemented, or are plans in place?
>

Just to be sure I understand.
You have internal users - they are in AD. You have external users - they
are in LDAP.
You merge two directories and you want to replace this setup with IPA.

IPA can trust AD. Formally it is a mutual trust but in reality IPA does
not have global catalog support for users in IPA to be able to access
the resources in AD. So it is one way trust due to limited
functionality. The global catalog support is being worked on. As soon as
it is implemented we will add more granularity to the way the trusts are
established and thus allow formal one way trusts.

It seems that to support your use case you would need to make the
external users be IPA users and make AD and IPA trust each other. Also
if external users do not authenticate using Kerberos (for example they
always use a special portal) then it does not matter what trust is
between AD and IPA because those users will not have kerberos tickets
that are leveraged in SSO in trust case.

HTH.


>  
>
> Thanks much,
>
> Bryce
>
>  
>
> [1] https://www.redhat.com/archives/freeipa-users/2012-June/msg00206.html
>
>
>
>
>
> This electronic message contains information generated by the USDA
> solely for the intended recipients. Any unauthorized interception of
> this message or the use or disclosure of the information it contains
> may violate the law and subject the violator to civil or criminal
> penalties. If you believe you have received this message in error,
> please notify the sender and delete the email immediately.
>
>
> ___
> 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

[Freeipa-users] One way trusts

[Nordgren, Bryce L -FS]

Hello,

I manage a suite of machines and services which are used for collaborative 
projects with external partners. I want to allow users within our organization 
to authenticate with their existing Active Directory accounts, and I have set 
up an "External Users" LDAP directory to establish identities for our partners. 
I have an LDAP server set up which merges the two directories and which 
forwards requests on to the correct directory.

I like the idea of FreeIPA, however, I need support for a one-way trust. I 
don't have the ability to modify any entries in our AD server, but I do have a 
normal user account (hence I can bind to AD's LDAP interface). However, I think 
this is kind of  a moot point since external users should under no 
circumstances be allowed access to our internal network/services. Read-only 
access to AD is just peachy. I found this old message (June 2012) on your 
mailing list which suggests one-way trusts may be on your radar. [1] However, I 
looked through your Trac tickets and didn't see any follow up. Did I miss 
something? Is this already implemented, or are plans in place?

Thanks much,
Bryce

[1] https://www.redhat.com/archives/freeipa-users/2012-June/msg00206.html




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Keberos and LDAP password

[Dmitri Pal]

On 01/13/2014 05:04 PM, Bob wrote:
> I'm very new to IPA. I run a ODSEE and I need to add in krb5. ODSEE
> allows us to store the KRB5 data in ldap, but there is no easy means
> of keeping the LDAP and Kerberos password in sync for a given account.
>
> I understand that IPA supplies Kerberos services. But is the krb5
> password the same password that a LDAP bind would use. Meaning I have
> many applications that can not use Kerberos, but can use LDAP. Can
> these applications use IPA and expect that a given user account will
> have the LDAP password kept in sync with the krb5 password?

Yes. It is the same. You can use IPA with Kerberos and/or LDAP clients.

>
> thanks,
>
> Bob
>
>
> ___
> 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] Keberos and LDAP password

[Christian Hernandez]

>From what I understand I use currently...

You can use "just LDAP"...I'm currently using LDAP/KRB where
supported...and just straight LDAP on applications that don't support KRB


Thank you,

Christian Hernandez
1225 Los Angeles Street
Glendale, CA 91204
Phone: 877-782-2737 ext. 4566
Fax: 818-265-3152
christi...@4over.com 
www.4over.com 


On Mon, Jan 13, 2014 at 2:04 PM, Bob  wrote:

> I'm very new to IPA. I run a ODSEE and I need to add in krb5. ODSEE allows
> us to store the KRB5 data in ldap, but there is no easy means of keeping
> the LDAP and Kerberos password in sync for a given account.
>
> I understand that IPA supplies Kerberos services. But is the krb5 password
> the same password that a LDAP bind would use. Meaning I have many
> applications that can not use Kerberos, but can use LDAP. Can these
> applications use IPA and expect that a given user account will have the
> LDAP password kept in sync with the krb5 password?
>
> thanks,
>
> Bob
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] Keberos and LDAP password

[Bob]

I'm very new to IPA. I run a ODSEE and I need to add in krb5. ODSEE allows
us to store the KRB5 data in ldap, but there is no easy means of keeping
the LDAP and Kerberos password in sync for a given account.

I understand that IPA supplies Kerberos services. But is the krb5 password
the same password that a LDAP bind would use. Meaning I have many
applications that can not use Kerberos, but can use LDAP. Can these
applications use IPA and expect that a given user account will have the
LDAP password kept in sync with the krb5 password?

thanks,

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

Re: [Freeipa-users] Certificate system unavailable

[Sigbjorn Lie]

On 13/01/14 19:37, Rob Crittenden wrote:

Sigbjorn Lie wrote:




On Mon, January 13, 2014 16:34, Rob Crittenden wrote:

Sigbjorn Lie wrote:





On Mon, January 13, 2014 15:58, Rob Crittenden wrote:


Sigbjorn Lie wrote:



Hi,



I seem to have issues with the certificate system on my IPA 
installation. Looking up hosts
in the IPA WEBUI on any of the IPA servers says "Certificate 
format error: [Errno -8015]

error (-8015)
unknown".

I also notice that hosts says the certificate system is unavailable.



certmonger: Server failed request, will retry: 4301 (RPC failed 
at server.  Certificate
operation cannot be completed: Failure decoding Certificate 
Signing Request).



Looking at the pki-ca logs on the ipa servers I see that some 
selftest failed:




# tail -100 selftests.log
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
SelfTestSubsystem: Initializing self test

plugins:
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
SelfTestSubsystem:  loading all self test
plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] 
[20] [1] SelfTestSubsystem:
  loading all self test plugin instances 28697.main - 
[13/Jan/2014:15:06:33 CET] [20] [1]

SelfTestSubsystem:  loading all self test plugin
instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] 
[1] SelfTestSubsystem:
loading self test plugins in on-demand order 28697.main - 
[13/Jan/2014:15:06:33 CET] [20]

[1]
SelfTestSubsystem:  loading self test plugins in
startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
SelfTestSubsystem: Self test
plugins have been successfully loaded! 28697.main - 
[13/Jan/2014:15:06:34 CET] [20] [1]

SelfTestSubsystem: Running self test plugins
specified to be executed at startup: 28697.main - 
[13/Jan/2014:15:06:34 CET] [20] [1]

CAPresence:
CA is present
28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] 
SystemCertsVerification: system certs
verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] 
[1] SelfTestSubsystem: The

  CRITICAL self test plugin
called selftests.container.instance.SystemCertsVerification 
running at startup FAILED!


the pki-cad service is running and "pki-cad status" displays the 
ports available.

/etc/init.d/pki-cad status
pki-ca (pid 28697) is running...   [  OK  ]


My main consern is that the certmonger requests for renew of 
certificates for LDAP on 2 out

of 3
of the IPA servers has failed, and the current certificate is 
expiring the 19th of January,

under a week from now.

Do you have any suggestions to where I can start troubleshootng 
this issue?





Check the trust on the audit certificate:



# certutil -L -d /var/lib/pki-ca/alias/
...
auditSigningCert cert-pki-ca u,u,Pu

If the trust is not u,u,Pu then you can fix it with:



# certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert 
cert-pki-ca'

-t u,u,Pu



Then restart the CA and it should be ok.




Looks like this certificate is expired. This is the same output on 
all 3 of the ipa servers.



How can this be fixed?



# certutil -L -d /var/lib/pki-ca/alias/ -n "auditSigningCert 
cert-pki-ca"

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 5 (0x5)
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Issuer: "CN=Certificate Authority,O=DNS.DOMAIN"
Validity:
Not Before: Thu Jan 19 19:44:24 2012
Not After : Wed Jan 08 19:44:24 2014





Go back in time to the 7th or 8th and run:


# getcert resubmit -d /var/lib/pki-ca/alias -n "auditSigningCert
cert-pki-ca"

There may be other certs in a similar situation. getcert list will 
show you.





Ouch. That would be rather disruptive I suppose. There is quite a lot 
of activity going to this
server, not to mention it's the primary ntp and dns server for the 
network.


Do you suppose this todo list will work ?

Firewall off the rest of the network, leaving the ipa server alone
Stop ntpd
Set date to 8th of January
Run the getcert resubmit command.
Change date back to correct date
Start ntpd
Remove the firewall rules


Looks good. I'd restart the certmonger service rather than 
resubmitting each individually. Be prepared for renewal to not 
succeed. For some reason it didn't on and before expiration time so 
whatever problem existed then likely still remains.


So the question to ask is "what will I do if renewal fails again?"

Nothing catastrophic will happen, but it will likely mean having to 
roll forward again, debug, roll back, try again, and perhaps more than 
once. It's hard to say w/o knowing why it failed in the first place.


How many of the services is required to be restarted for the renewal 
to work after the date is

changed to the 7th?


The renewal itself should restart the required services.



This worked better than expected. Thank you! :)

ipa01 and ipa02 seem to be happy again, "getcert list" no longer 
displays any certificates out of date, and all certificates in need of 
renewal within 28 days has been renewed. The webui also started working 
again and things s

Re: [Freeipa-users] Odd problem with SSSD and SSH keys

[Jakub Hrozek]

On Mon, Jan 13, 2014 at 02:44:29PM -0500, Bret Wortman wrote:
> They're definitely different. I deleted the one in the file, then
> tried again. It put the bad key back in the file. I blew the whole
> file away and the same thing happened. Where is this key coming from
> if not from IPA?

Can you try running sss_ssh_knownhostsproxy manually to see what key
does it return?

The keys are propagated to the file from the sssd database. If the client
was offline, the client could use stale records. Can you verify the client
has no connectivity issues?

Honza (CC-ed) might have some more hints.

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

Re: [Freeipa-users] Manage records while primary IPA is down

[Dmitri Pal]

On 01/13/2014 03:01 PM, Dimitar Georgievski wrote:
>
> I was referring to user accounts, and I believe they require
> certificates. With the Primary IPA being down I was not able to create
> new user entries on the replica servers.

Hm? What kind of error you get? What does HTTP log shows on the replica
you are performing operation against?
User accounts have a certificate attribute but it is not used yet so it
might be something else not related to certificates.
Answers to the questions above would help.
Also here are some hints that might be helpful in collecting and
preparing information for our analysis: 
http://www.freeipa.org/page/Troubleshooting
>
> Hopefully the CA fail-over requirement is addressed in a new release
> of FreeIPA.
>
> Thanks,
>
> Dimitar
>
>
> On Mon, Jan 13, 2014 at 1:36 PM, Dmitri Pal  > wrote:
>
> On 01/13/2014 01:33 PM, Rob Crittenden wrote:
> > Dimitar Georgievski wrote:
> >> This question is really about HA of FreeIPA. I've noticed that new
> >> records cannot be added on the replica server while the primary
> is down.
> >>
> >> Ideally these services should be always available even when the
> Primary
> >> server is down (for maintenance or other reasons).
> >>
> >> Is it possible to have another Primary server replicating with
> the first
> >> Primary or to use one of the Replica servers to manage records
> while the
> >> Primary server is down.
> >
> > All servers in IPA are equal masters, the only difference may be the
> > services running on any given server (DNS and a CA).
> >
> > The exception is if a master runs out of DNA values or has never
> been
> > used to add an entry that requires one and the original IPA
> master is
> > down. An IPA server will request a DNA range the first time it needs
> > one but doesn't get one until then. I'm guessing that is what
> happened.
> >
> > I believe IPA 3.3 added some options to ipa-replica-manage to be
> able
> > to control the DNA configuration.
>
>
> We might be talking about the entries that have certificates. Is this
> the case?
> If so the certificate operations are proxied to the server that
> has full
> CA but AFAIR there is not failover there and I vaguely recall that
> there
> was ticket filed to address this scenario.
>
> So which entries we are talking about?
>
> >
> > rob
> >
> > ___
> > 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
>
>


-- 
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] Manage records while primary IPA is down

[Dimitar Georgievski]

I was referring to user accounts, and I believe they require certificates.
With the Primary IPA being down I was not able to create new user entries
on the replica servers.

Hopefully the CA fail-over requirement is addressed in a new release of
FreeIPA.

Thanks,

Dimitar


On Mon, Jan 13, 2014 at 1:36 PM, Dmitri Pal  wrote:

> On 01/13/2014 01:33 PM, Rob Crittenden wrote:
> > Dimitar Georgievski wrote:
> >> This question is really about HA of FreeIPA. I've noticed that new
> >> records cannot be added on the replica server while the primary is down.
> >>
> >> Ideally these services should be always available even when the Primary
> >> server is down (for maintenance or other reasons).
> >>
> >> Is it possible to have another Primary server replicating with the first
> >> Primary or to use one of the Replica servers to manage records while the
> >> Primary server is down.
> >
> > All servers in IPA are equal masters, the only difference may be the
> > services running on any given server (DNS and a CA).
> >
> > The exception is if a master runs out of DNA values or has never been
> > used to add an entry that requires one and the original IPA master is
> > down. An IPA server will request a DNA range the first time it needs
> > one but doesn't get one until then. I'm guessing that is what happened.
> >
> > I believe IPA 3.3 added some options to ipa-replica-manage to be able
> > to control the DNA configuration.
>
>
> We might be talking about the entries that have certificates. Is this
> the case?
> If so the certificate operations are proxied to the server that has full
> CA but AFAIR there is not failover there and I vaguely recall that there
> was ticket filed to address this scenario.
>
> So which entries we are talking about?
>
> >
> > rob
> >
> > ___
> > 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
>
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Odd problem with SSSD and SSH keys

[Dmitri Pal]

On 01/13/2014 02:44 PM, Bret Wortman wrote:
> They're definitely different. I deleted the one in the file, then
> tried again. It put the bad key back in the file. I blew the whole
> file away and the same thing happened. Where is this key coming from
> if not from IPA?

Puppet?

>
>
> On 01/13/2014 02:36 PM, Rob Crittenden wrote:
>> Bret Wortman wrote:
>>> I've got a strange situation where some of my workstations are
>>> reporting
>>> difficulty when sshing to remote systems, but there's no pattern I can
>>> discern. One user's machine can't get to system A, but I can, though I
>>> can't ssh to his workstation directly.
>>>
>>> Here's the kind of thing I see when doing ssh -vvv:
>>>
>>> debug1: Server host key: RSA
>>> 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab
>>> debug3: load_hostkeys: loading entries for host "rs512" from file
>>> "/root/.ssh/known_hosts"
>>> debug3: load_hostkeys: loaded 0 keys
>>> debug3: load_hostkeys: loading entries for host "rs512" from file
>>> "/var/lib/sss/pubconf/known_hosts"
>>> debug3: load_hostkeys: found key type RSA in file
>>> /var/lib/sss/pubconf/known_hosts:2
>>> debug3: load_hostkeys: loaded 1 keys
>>> @@
>>> @   WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
>>> @@
>>> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
>>> Someone coudl be eavesdropping on you right now (man-in-the-middle
>>> attack)!
>>> It is also possible that a host key has just been changed.
>>> The fingerprint for the RSA key sent by the remote host is
>>> 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab
>>> Please contact your system administrator.
>>> Add correct host key in /root/.ssh/known_hosts to get rid of this
>>> message.
>>> Offending RSA key in /var/lib/sss/pubconf/known_hosts:2
>>> RSA host key for zw131 has changed and you have requested strict
>>> checking.
>>> Host key verification failed.
>>> #
>>>
>>> We haven't changed the host key; the public key files are dated October
>>> 23 of last year. Our configuration files for SSSD and SSH are
>>> managed by
>>> Puppet, so they are consistent from system to system. That said, I did
>>> compare a system that could remote to rs512 to one that could not and
>>> found no differences. Here are the files:
>>>
>>> /etc/sssd/sssd.conf:
>>> [domain/spx.net]
>>> cache_credentials = True
>>> krb5_store_password_if_offline = True
>>> ipa_domain = foo.net
>>> id_provider = ipa
>>> auth_provider = ipa
>>> access_provider = ipa
>>> ipa_hostname = zw129.foo.net
>>> chpass_provider = ipa
>>> ipa_dyndns_update = True
>>> ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49
>>> ldap_tls_cacert = /etc/ipa/ca.crt
>>> [domain/.spx.net]
>>> cache_credentials = True
>>> krb5_store_password_if_offline = True
>>> krb5_realm = FOO.NET
>>> ipa_domain = .foo.net
>>> id_provider = ipa
>>> auth_provider = ipa
>>> access_provider = ipa
>>> ldap_tls_cacert = /etc/ipa/ca.crt
>>> chpass_provider = ipa
>>> ipa_dyndns_update = True
>>> ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49
>>> ldap_netgroup_search_base = cn=ng,cn=compat,dc=foo,dc=net
>>> dns_discovery_domain = .spx.net
>>> [sssd]
>>> services = nss, pam, ssh
>>> config_file_version = 2
>>>
>>> domains = .spx.net, spx.net
>>> [nss]
>>>
>>> [pam]
>>>
>>> [sudo]
>>>
>>> [autofs]
>>>
>>> [ssh]
>>>
>>> Is there anything else relevant that I should be looking at?
>>
>> You might compare the value of the key in IPA to what is in
>> /var/lib/sss/pubconf/known_hosts
>>
>> rob
>>
>
>
>
>
> ___
> 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] Odd problem with SSSD and SSH keys

[Bret Wortman]

They're definitely different. I deleted the one in the file, then tried 
again. It put the bad key back in the file. I blew the whole file away 
and the same thing happened. Where is this key coming from if not from IPA?



On 01/13/2014 02:36 PM, Rob Crittenden wrote:

Bret Wortman wrote:

I've got a strange situation where some of my workstations are reporting
difficulty when sshing to remote systems, but there's no pattern I can
discern. One user's machine can't get to system A, but I can, though I
can't ssh to his workstation directly.

Here's the kind of thing I see when doing ssh -vvv:

debug1: Server host key: RSA 
2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab

debug3: load_hostkeys: loading entries for host "rs512" from file
"/root/.ssh/known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug3: load_hostkeys: loading entries for host "rs512" from file
"/var/lib/sss/pubconf/known_hosts"
debug3: load_hostkeys: found key type RSA in file
/var/lib/sss/pubconf/known_hosts:2
debug3: load_hostkeys: loaded 1 keys
@@
@   WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone coudl be eavesdropping on you right now (man-in-the-middle 
attack)!

It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this 
message.

Offending RSA key in /var/lib/sss/pubconf/known_hosts:2
RSA host key for zw131 has changed and you have requested strict 
checking.

Host key verification failed.
#

We haven't changed the host key; the public key files are dated October
23 of last year. Our configuration files for SSSD and SSH are managed by
Puppet, so they are consistent from system to system. That said, I did
compare a system that could remote to rs512 to one that could not and
found no differences. Here are the files:

/etc/sssd/sssd.conf:
[domain/spx.net]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = foo.net
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = zw129.foo.net
chpass_provider = ipa
ipa_dyndns_update = True
ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49
ldap_tls_cacert = /etc/ipa/ca.crt
[domain/.spx.net]
cache_credentials = True
krb5_store_password_if_offline = True
krb5_realm = FOO.NET
ipa_domain = .foo.net
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ldap_tls_cacert = /etc/ipa/ca.crt
chpass_provider = ipa
ipa_dyndns_update = True
ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49
ldap_netgroup_search_base = cn=ng,cn=compat,dc=foo,dc=net
dns_discovery_domain = .spx.net
[sssd]
services = nss, pam, ssh
config_file_version = 2

domains = .spx.net, spx.net
[nss]

[pam]

[sudo]

[autofs]

[ssh]

Is there anything else relevant that I should be looking at?


You might compare the value of the key in IPA to what is in 
/var/lib/sss/pubconf/known_hosts


rob






smime.p7s
Description: S/MIME Cryptographic Signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Odd problem with SSSD and SSH keys

[Rob Crittenden]

Bret Wortman wrote:

I've got a strange situation where some of my workstations are reporting
difficulty when sshing to remote systems, but there's no pattern I can
discern. One user's machine can't get to system A, but I can, though I
can't ssh to his workstation directly.

Here's the kind of thing I see when doing ssh -vvv:

debug1: Server host key: RSA 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab
debug3: load_hostkeys: loading entries for host "rs512" from file
"/root/.ssh/known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug3: load_hostkeys: loading entries for host "rs512" from file
"/var/lib/sss/pubconf/known_hosts"
debug3: load_hostkeys: found key type RSA in file
/var/lib/sss/pubconf/known_hosts:2
debug3: load_hostkeys: loaded 1 keys
@@
@   WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone coudl be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending RSA key in /var/lib/sss/pubconf/known_hosts:2
RSA host key for zw131 has changed and you have requested strict checking.
Host key verification failed.
#

We haven't changed the host key; the public key files are dated October
23 of last year. Our configuration files for SSSD and SSH are managed by
Puppet, so they are consistent from system to system. That said, I did
compare a system that could remote to rs512 to one that could not and
found no differences. Here are the files:

/etc/sssd/sssd.conf:
[domain/spx.net]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = foo.net
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = zw129.foo.net
chpass_provider = ipa
ipa_dyndns_update = True
ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49
ldap_tls_cacert = /etc/ipa/ca.crt
[domain/.spx.net]
cache_credentials = True
krb5_store_password_if_offline = True
krb5_realm = FOO.NET
ipa_domain = .foo.net
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ldap_tls_cacert = /etc/ipa/ca.crt
chpass_provider = ipa
ipa_dyndns_update = True
ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49
ldap_netgroup_search_base = cn=ng,cn=compat,dc=foo,dc=net
dns_discovery_domain = .spx.net
[sssd]
services = nss, pam, ssh
config_file_version = 2

domains = .spx.net, spx.net
[nss]

[pam]

[sudo]

[autofs]

[ssh]

Is there anything else relevant that I should be looking at?


You might compare the value of the key in IPA to what is in 
/var/lib/sss/pubconf/known_hosts


rob

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

[Freeipa-users] Odd problem with SSSD and SSH keys

[Bret Wortman]

  
  
I've got a strange situation where some of my workstations are
reporting difficulty when sshing to remote systems, but there's no
pattern I can discern. One user's machine can't get to system A, but
I can, though I can't ssh to his workstation directly.

Here's the kind of thing I see when doing ssh -vvv:

debug1: Server host
  key: RSA 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab
  debug3: load_hostkeys: loading entries for host "rs512" from file
  "/root/.ssh/known_hosts"
  debug3: load_hostkeys: loaded 0 keys
  debug3: load_hostkeys: loading entries for host "rs512" from file
  "/var/lib/sss/pubconf/known_hosts"
  debug3: load_hostkeys: found key type RSA in file
  /var/lib/sss/pubconf/known_hosts:2
  debug3: load_hostkeys: loaded 1 keys
  @@
  @   WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
  @@
  IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
  Someone coudl be eavesdropping on you right now (man-in-the-middle
  attack)!
  It is also possible that a host key has just been changed.
  The fingerprint for the RSA key sent by the remote host is
  2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab
  Please contact your system administrator.
  Add correct host key in /root/.ssh/known_hosts to get rid of this
  message.
  Offending RSA key in /var/lib/sss/pubconf/known_hosts:2
  RSA host key for zw131 has changed and you have requested strict
  checking.
  Host key verification failed.
  #

We haven't changed the host key; the public key files are dated
October 23 of last year. Our configuration files for SSSD and SSH
are managed by Puppet, so they are consistent from system to system.
That said, I did compare a system that could remote to rs512 to one
that could not and found no differences. Here are the files:

/etc/sssd/sssd.conf:
[domain/spx.net]
  cache_credentials = True
  krb5_store_password_if_offline = True
  ipa_domain = foo.net
  id_provider = ipa
  auth_provider = ipa
  access_provider = ipa
  ipa_hostname = zw129.foo.net
  chpass_provider = ipa
  ipa_dyndns_update = True
  ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49
  ldap_tls_cacert = /etc/ipa/ca.crt
  [domain/.spx.net]
  cache_credentials = True
  krb5_store_password_if_offline = True
  krb5_realm = FOO.NET
  ipa_domain = .foo.net
  id_provider = ipa
  auth_provider = ipa
  access_provider = ipa
  ldap_tls_cacert = /etc/ipa/ca.crt
  chpass_provider = ipa
  ipa_dyndns_update = True
  ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49
  ldap_netgroup_search_base = cn=ng,cn=compat,dc=foo,dc=net
  dns_discovery_domain = .spx.net
  [sssd]
  services = nss, pam, ssh
  config_file_version = 2
  
  domains = .spx.net, spx.net
  [nss]
  
  [pam]
  
  [sudo]
  
  [autofs]
  
  [ssh]

Is there anything else relevant that I should be looking at?


-- 
  Bret Wortman
  
  
  http://damascusgrp.com/
  
  http://about.me/wortmanbret

  

  



smime.p7s
Description: S/MIME Cryptographic Signature
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Manage records while primary IPA is down

[Dmitri Pal]

On 01/13/2014 01:33 PM, Rob Crittenden wrote:
> Dimitar Georgievski wrote:
>> This question is really about HA of FreeIPA. I've noticed that new
>> records cannot be added on the replica server while the primary is down.
>>
>> Ideally these services should be always available even when the Primary
>> server is down (for maintenance or other reasons).
>>
>> Is it possible to have another Primary server replicating with the first
>> Primary or to use one of the Replica servers to manage records while the
>> Primary server is down.
>
> All servers in IPA are equal masters, the only difference may be the
> services running on any given server (DNS and a CA).
>
> The exception is if a master runs out of DNA values or has never been
> used to add an entry that requires one and the original IPA master is
> down. An IPA server will request a DNA range the first time it needs
> one but doesn't get one until then. I'm guessing that is what happened.
>
> I believe IPA 3.3 added some options to ipa-replica-manage to be able
> to control the DNA configuration.


We might be talking about the entries that have certificates. Is this
the case?
If so the certificate operations are proxied to the server that has full
CA but AFAIR there is not failover there and I vaguely recall that there
was ticket filed to address this scenario.

So which entries we are talking about?

>
> rob
>
> ___
> 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] Certificate system unavailable

[Rob Crittenden]

Sigbjorn Lie wrote:




On Mon, January 13, 2014 16:34, Rob Crittenden wrote:

Sigbjorn Lie wrote:





On Mon, January 13, 2014 15:58, Rob Crittenden wrote:


Sigbjorn Lie wrote:



Hi,



I seem to have issues with the certificate system on my IPA installation. 
Looking up hosts
in the IPA WEBUI on any of the IPA servers says "Certificate format error: 
[Errno -8015]
error (-8015)
unknown".

I also notice that hosts says the certificate system is unavailable.



certmonger: Server failed request, will retry: 4301 (RPC failed at server.  
Certificate
operation cannot be completed: Failure decoding Certificate Signing Request).


Looking at the pki-ca logs on the ipa servers I see that some selftest failed:



# tail -100 selftests.log
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: 
Initializing self test
plugins:
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  loading 
all self test
plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
SelfTestSubsystem:
  loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 
CET] [20] [1]
SelfTestSubsystem:  loading all self test plugin
instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
SelfTestSubsystem:
loading self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 
CET] [20]
[1]
SelfTestSubsystem:  loading self test plugins in
startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
SelfTestSubsystem: Self test
plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 CET] 
[20] [1]
SelfTestSubsystem: Running self test plugins
specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] 
[20] [1]
CAPresence:
CA is present
28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: 
system certs
verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] 
SelfTestSubsystem: The
  CRITICAL self test plugin
called selftests.container.instance.SystemCertsVerification running at startup 
FAILED!

the pki-cad service is running and "pki-cad status" displays the ports 
available.
/etc/init.d/pki-cad status
pki-ca (pid 28697) is running...   [  OK  ]


My main consern is that the certmonger requests for renew of certificates for 
LDAP on 2 out
of 3
of the IPA servers has failed, and the current certificate is expiring the 19th 
of January,
under a week from now.

Do you have any suggestions to where I can start troubleshootng this issue?




Check the trust on the audit certificate:



# certutil -L -d /var/lib/pki-ca/alias/
...
auditSigningCert cert-pki-ca u,u,Pu

If the trust is not u,u,Pu then you can fix it with:



# certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca'
-t u,u,Pu



Then restart the CA and it should be ok.




Looks like this certificate is expired. This is the same output on all 3 of the 
ipa servers.


How can this be fixed?



# certutil -L -d /var/lib/pki-ca/alias/ -n "auditSigningCert cert-pki-ca"
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 5 (0x5)
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Issuer: "CN=Certificate Authority,O=DNS.DOMAIN"
Validity:
Not Before: Thu Jan 19 19:44:24 2012
Not After : Wed Jan 08 19:44:24 2014





Go back in time to the 7th or 8th and run:


# getcert resubmit -d /var/lib/pki-ca/alias -n "auditSigningCert
cert-pki-ca"

There may be other certs in a similar situation. getcert list will show you.




Ouch. That would be rather disruptive I suppose. There is quite a lot of 
activity going to this
server, not to mention it's the primary ntp and dns server for the network.

Do you suppose this todo list will work ?

Firewall off the rest of the network, leaving the ipa server alone
Stop ntpd
Set date to 8th of January
Run the getcert resubmit command.
Change date back to correct date
Start ntpd
Remove the firewall rules


Looks good. I'd restart the certmonger service rather than resubmitting 
each individually. Be prepared for renewal to not succeed. For some 
reason it didn't on and before expiration time so whatever problem 
existed then likely still remains.


So the question to ask is "what will I do if renewal fails again?"

Nothing catastrophic will happen, but it will likely mean having to roll 
forward again, debug, roll back, try again, and perhaps more than once. 
It's hard to say w/o knowing why it failed in the first place.



How many of the services is required to be restarted for the renewal to work 
after the date is
changed to the 7th?


The renewal itself should restart the required services.

rob

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

Re: [Freeipa-users] Manage records while primary IPA is down

[Rob Crittenden]

Dimitar Georgievski wrote:

This question is really about HA of FreeIPA. I've noticed that new
records cannot be added on the replica server while the primary is down.

Ideally these services should be always available even when the Primary
server is down (for maintenance or other reasons).

Is it possible to have another Primary server replicating with the first
Primary or to use one of the Replica servers to manage records while the
Primary server is down.


All servers in IPA are equal masters, the only difference may be the 
services running on any given server (DNS and a CA).


The exception is if a master runs out of DNA values or has never been 
used to add an entry that requires one and the original IPA master is 
down. An IPA server will request a DNA range the first time it needs one 
but doesn't get one until then. I'm guessing that is what happened.


I believe IPA 3.3 added some options to ipa-replica-manage to be able to 
control the DNA configuration.


rob

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

[Freeipa-users] Manage records while primary IPA is down

[Dimitar Georgievski]

This question is really about HA of FreeIPA. I've noticed that new records
cannot be added on the replica server while the primary is down.

Ideally these services should be always available even when the Primary
server is down (for maintenance or other reasons).

Is it possible to have another Primary server replicating with the first
Primary or to use one of the Replica servers to manage records while the
Primary server is down.

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

Re: [Freeipa-users] Certificate system unavailable

[Sigbjorn Lie]

On 13/01/14 19:13, Nalin Dahyabhai wrote:

On Mon, Jan 13, 2014 at 04:07:16PM +0100, Sigbjorn Lie wrote:

After I restarted dirsrv, pki-cad and then the httpd on ipa01 the status of the 
request is now:

Request ID '20120119194518':
status: CA_UNREACHABLE
ca-error: Server failed request, will retry: 907 (RPC failed at server. 
 cannot connect to
'https://ipa01.dns.domain:443/ca/agent/ca/displayBySerial': [Errno -12269]
(SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.).
stuck: yes
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS
 Certificate
DB',pinfile='/etc/dirsrv/slapd-DNS-DOMAIN//pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=DNS-DOMAIN
subject: CN=ipa01.dns.domain,O=DNS-DOMAIN
expires: 2014-01-19 19:45:18 UTC
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes

However I cannot find the certificate that's expired?

That error message was the one the IPA server received and then relayed
back to certmonger, so I'd expect that the expired certificate is the
agent certificate that IPA uses when connecting to the CA's agent
interface.  That's stored in the NSS database in /etc/httpd/alias, with
nickname "ipaCert".




Yes, the ipaCert certificate in /etc/httpd/alias/ is expired.

Actually all certificates in /var/lib/pki-ca/alias/ is expired too, they 
all expired at the same date, within minutes of each other. It looks 
like they are the original certificates issued when I installed IPA, 
when I look at the "Not Before" timestamp of the certificates.




Regards,
Siggi

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

Re: [Freeipa-users] Certificate system unavailable

[Nalin Dahyabhai]

On Mon, Jan 13, 2014 at 04:07:16PM +0100, Sigbjorn Lie wrote:
> After I restarted dirsrv, pki-cad and then the httpd on ipa01 the status of 
> the request is now:
> 
> Request ID '20120119194518':
>   status: CA_UNREACHABLE
>   ca-error: Server failed request, will retry: 907 (RPC failed at server. 
>  cannot connect to
> 'https://ipa01.dns.domain:443/ca/agent/ca/displayBySerial': [Errno -12269]
> (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as 
> expired.).
>   stuck: yes
>   key pair storage:
> type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS
>  Certificate
> DB',pinfile='/etc/dirsrv/slapd-DNS-DOMAIN//pwdfile.txt'
>   certificate: 
> type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS
> Certificate DB'
>   CA: IPA
>   issuer: CN=Certificate Authority,O=DNS-DOMAIN
>   subject: CN=ipa01.dns.domain,O=DNS-DOMAIN
>   expires: 2014-01-19 19:45:18 UTC
>   eku: id-kp-serverAuth,id-kp-clientAuth
>   pre-save command:
>   post-save command:
>   track: yes
>   auto-renew: yes
> 
> However I cannot find the certificate that's expired?

That error message was the one the IPA server received and then relayed
back to certmonger, so I'd expect that the expired certificate is the
agent certificate that IPA uses when connecting to the CA's agent
interface.  That's stored in the NSS database in /etc/httpd/alias, with
nickname "ipaCert".

HTH,

Nalin

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

Re: [Freeipa-users] Updated doc, synchronization question

[William Muriithi]

> > >  Two questions:
> > > 
> > >  - Any ETA on an updated 3.3.3 Users Guide?
> > > >>>
> > > >>> Our current plan is to release next documentation release along
with
> > > >>> FreeIPA
> > > >>> 3.4, when more documentation fixes are factored in.
> > > >>>
> >
> > Would you by any chance know when FreeIPA 3.4 will be realised?
> >
> > Looking to update a version 2.2 and would wait for 3.4 if its
> > reasonably soon.
> >
>
> We planned for Feb but it seems like it would slip. How much is unclear.
> We might reduce the scope and cut it earlier (I mean do not slip too
> much) or try to keep the scope and extend the time couple months.
> We will decide in early Feb.

Thanks a lot for the estimated release date. Please do make some
announcement once you guys make up your mind which route to take.

William
>
> Sorry not to have a more precise answer.
>
> Thanks
> Dmitri
>
> > William
> >
> > > >>> Just in case you would like to check the most recent status of the
> > > >>> documentation work (or even help us with it), this page describes
> > > >>> the details
> > > >>>
> > > >>> http://www.freeipa.org/page/Contribute/Documentation
> > > >>>
> > > >>> including instructions how to build HTMLs out of our git tree.
> > > >>>
> > > >>
> > > >> Thanks, I'll take a look.
> > > >>
> > >  - Is AD/IPA synchronization still supported in 3.3.3?  Will it
> > always?
> > > >>>
> > > >>> The AD/IPA synchronization is supported only in terms in bug
fixes.
> > > >>> As for the
> > > >>> enhancements, the FreeIPA core team is focusing on the AD trusts:
> > > >>>
> > > >>> http://www.freeipa.org/page/Trusts
> > > >>>
> > > >>> (That does not mean we are not open to contributions from the
> > > >>> community)
> > > >>>
> > > >>> Martin
> > > >>>
> > > >>
> > > >> Thanks for the that link - the video was helpful.  Although I'm
> > > >> afraid that is
> > > >> making me lean towards implementing the not recommended "split
brain"
> > > >> approach.  Although one thing that is not clear to me is weather
> > > >> doing this
> > > >> consumes CALs for the linux machines since they authenticate
> > against AD.
> > > > Linux machines do not authenticate against AD DC in single sign-on
> > > > case. Instead, usually Windows users obtain their Kerberos TGT upon
> > > > logon to
> > > > Windows machines and then use it to obtain tickets to services on
> > Linux
> > > > machines, by obtaining cross-realm TGT from AD DC and presenting it
to
> > > > IPA KDC as a proof. So in single sign-on case it works fine --
> > > > authentication against AD happens on AD side.
> > > >
> > > > Of course, when AD users attempt to log in with password to IPA
> > > > resources, SSSD would perform communication with AD DC to obtain
> > TGT on
> > > > their behalf. There is AD DC involved in making a decision whether
> > > > this AD user is allowed to authenticate. On Kerberos level, however,
> > > > there are no limitations from where the authentication request comes
> > > > (unless it is restricted with the firewalls). CALs play role on
using
> > > > Windows resources after authentication happened but in IPA AD trusts
> > > > case currently only IPA resources can be consumed by AD users, IPA
> > users
> > > > cannot yet consume Windows resources and therefore get assigned
rights
> > > > to access them.
> > > >
> > >
> > > To clarify the CAL part.
> > > The CALs come in two shapes: per user and per host.
> > > If it is per user and you have users in AD then regardless of how you
> > > integrate with IPA you have to pay these CALs.
> > > If your CALs is around hosts then they are based on the count of the
> > > computer objects in AD.
> > > If the client system is joined directly and has kerberos identity in
AD
> > > domain you have an object in AD that counts towards CALs.
> > > If you have client joined to IPA and either trust or sync solution in
> > > place the client is not a member of AD (no computer object in AD) and
> > > this does not count towards CALs.
> > >
> > > HTH
> > >
> > >
> > >
> > >
> > > --
> > > Thank you,
> > > Dmitri Pal
> > >
> > > Sr. Engineering Manager for IdM portfolio
> > > Red Hat Inc.
> > >
> > >
> >
> >
> >
> > ___
> > 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/
>
>
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
https://www.redhat.com/archives/freeipa-users/attachments/20140112/fe887df9/attachment.html
>
>
> ---
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Certificate system unavailable

[Sigbjorn Lie]

On Mon, January 13, 2014 16:17, Rob Crittenden wrote:
> Sigbjorn Lie wrote:
>
>> Hi,
>>
>>
>> Thank you for your prompt reply Rob.
>>
>>
>>
>> On Mon, January 13, 2014 15:58, Rob Crittenden wrote:
>>
>>> Sigbjorn Lie wrote:
>>>
>>>
 Hi,



 I seem to have issues with the certificate system on my IPA installation. 
 Looking up hosts
 in the IPA WEBUI on any of the IPA servers says "Certificate format error: 
 [Errno -8015]
 error (-8015)
 unknown".

 I also notice that hosts says the certificate system is unavailable.



 certmonger: Server failed request, will retry: 4301 (RPC failed at server. 
  Certificate
 operation cannot be completed: Failure decoding Certificate Signing 
 Request).


 Looking at the pki-ca logs on the ipa servers I see that some selftest 
 failed:



 # tail -100 selftests.log
 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: 
 Initializing self test
 plugins:
 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  
 loading all self test
 plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
 SelfTestSubsystem:
  loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 
 CET] [20] [1]
 SelfTestSubsystem:  loading all self test plugin
 instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
 SelfTestSubsystem:
 loading self test plugins in on-demand order 28697.main - 
 [13/Jan/2014:15:06:33 CET] [20]
 [1]
 SelfTestSubsystem:  loading self test plugins in
 startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
 SelfTestSubsystem: Self test
 plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 
 CET] [20] [1]
 SelfTestSubsystem: Running self test plugins
 specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 
 CET] [20] [1]
 CAPresence:
 CA is present
 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: 
 system certs
 verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] 
 SelfTestSubsystem: The
  CRITICAL self test plugin
 called selftests.container.instance.SystemCertsVerification running at 
 startup FAILED!

 the pki-cad service is running and "pki-cad status" displays the ports 
 available.
 /etc/init.d/pki-cad status
 pki-ca (pid 28697) is running...   [  OK  ]


 My main consern is that the certmonger requests for renew of certificates 
 for LDAP on 2 out
 of 3
 of the IPA servers has failed, and the current certificate is expiring the 
 19th of January,
 under a week from now.

 Do you have any suggestions to where I can start troubleshootng this issue?


>>>
>>> Check the trust on the audit certificate:
>>>
>>>
>>>
>>> # certutil -L -d /var/lib/pki-ca/alias/
>>> ...
>>> auditSigningCert cert-pki-ca u,u,Pu
>>
>> All the 3 ipa servers return u,u,Pu for auditSigningCert
>>
>>
>> # certutil -L -d /var/lib/pki-ca/alias/
>>
>>
>> Certificate Nickname Trust Attributes
>> SSL,S/MIME,JAR/XPI
>>
>>
>> caSigningCert cert-pki-caCTu,Cu,Cu 
>> Server-Cert cert-pki-ca
>> u,u,u auditSigningCert cert-pki-ca u,u,Pu 
>> ocspSigningCert
>> cert-pki-ca  u,u,u subsystemCert cert-pki-ca
>> u,u,u
>>
>>>
>>> If the trust is not u,u,Pu then you can fix it with:
>>>
>>>
>>>
>>> # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca'
>>> -t u,u,Pu
>>>
>>>
>>>
>>> Then restart the CA and it should be ok.
>>>
>>>
>>
>> I have restarted the dirsrv for PKI-IPA, and the pki-cad service on all 3 
>> IPA servers.
>>
>>
>>>
>>> What is the status on the failed certmonger requests?
>>>
>>
>> After I restarted dirsrv, pki-cad and then the httpd on ipa01 the status of 
>> the request is now:
>>
>>
>> Request ID '20120119194518':
>> status: CA_UNREACHABLE
>> ca-error: Server failed request, will retry: 907 (RPC failed at server.  
>> cannot connect to
>> 'https://ipa01.dns.domain:443/ca/agent/ca/displayBySerial': [Errno -12269]
>> (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as 
>> expired.).
>> stuck: yes
>> key pair storage:
>> type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS
>> Certificate
>> DB',pinfile='/etc/dirsrv/slapd-DNS-DOMAIN//pwdfile.txt'
>> certificate:
>> type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS
>>  Certificate
>> DB'
>> CA: IPA
>> issuer: CN=Certificate Authority,O=DNS-DOMAIN
>> subject: CN=ipa01.dns.domain,O=DNS-DOMAIN
>> expires: 2014-01-19 19:45:18 UTC
>> eku: id-kp-serverAuth,id-kp-clientAuth
>> pre-save command: post

Re: [Freeipa-users] Certificate system unavailable

[Sigbjorn Lie]

Hi,

Thank you for your prompt reply Rob.


On Mon, January 13, 2014 15:58, Rob Crittenden wrote:
> Sigbjorn Lie wrote:
>
>> Hi,
>>
>>
>> I seem to have issues with the certificate system on my IPA installation. 
>> Looking up hosts in
>> the IPA WEBUI on any of the IPA servers says "Certificate format error: 
>> [Errno -8015] error
>> (-8015)
>> unknown".
>>
>> I also notice that hosts says the certificate system is unavailable.
>>
>>
>> certmonger: Server failed request, will retry: 4301 (RPC failed at server.  
>> Certificate
>> operation cannot be completed: Failure decoding Certificate Signing Request).
>>
>>
>> Looking at the pki-ca logs on the ipa servers I see that some selftest 
>> failed:
>>
>>
>> # tail -100 selftests.log
>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: 
>> Initializing self test
>> plugins:
>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  loading 
>> all self test
>> plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
>> SelfTestSubsystem:
>> loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 
>> CET] [20] [1]
>> SelfTestSubsystem:  loading all self test plugin
>> instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
>> SelfTestSubsystem:  loading
>> self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 CET] 
>> [20] [1]
>> SelfTestSubsystem:  loading self test plugins in
>> startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
>> SelfTestSubsystem: Self test
>> plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 
>> CET] [20] [1]
>> SelfTestSubsystem: Running self test plugins
>> specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] 
>> [20] [1] CAPresence:
>> CA is present
>> 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: 
>> system certs
>> verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] 
>> SelfTestSubsystem: The
>> CRITICAL self test plugin
>> called selftests.container.instance.SystemCertsVerification running at 
>> startup FAILED!
>>
>> the pki-cad service is running and "pki-cad status" displays the ports 
>> available.
>> /etc/init.d/pki-cad status
>> pki-ca (pid 28697) is running...   [  OK  ]
>>
>>
>> My main consern is that the certmonger requests for renew of certificates 
>> for LDAP on 2 out of
>> 3
>> of the IPA servers has failed, and the current certificate is expiring the 
>> 19th of January,
>> under a week from now.
>>
>> Do you have any suggestions to where I can start troubleshootng this issue?
>>
>
> Check the trust on the audit certificate:
>
>
> # certutil -L -d /var/lib/pki-ca/alias/
> ...
> auditSigningCert cert-pki-ca u,u,Pu

All the 3 ipa servers return u,u,Pu for auditSigningCert

# certutil -L -d /var/lib/pki-ca/alias/

Certificate Nickname Trust Attributes
 SSL,S/MIME,JAR/XPI

caSigningCert cert-pki-caCTu,Cu,Cu
Server-Cert cert-pki-ca  u,u,u
auditSigningCert cert-pki-ca u,u,Pu
ocspSigningCert cert-pki-ca  u,u,u
subsystemCert cert-pki-cau,u,u

>
> If the trust is not u,u,Pu then you can fix it with:
>
>
> # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca'
> -t u,u,Pu
>
>
> Then restart the CA and it should be ok.
>

I have restarted the dirsrv for PKI-IPA, and the pki-cad service on all 3 IPA 
servers.

>
> What is the status on the failed certmonger requests?

After I restarted dirsrv, pki-cad and then the httpd on ipa01 the status of the 
request is now:

Request ID '20120119194518':
status: CA_UNREACHABLE
ca-error: Server failed request, will retry: 907 (RPC failed at server. 
 cannot connect to
'https://ipa01.dns.domain:443/ca/agent/ca/displayBySerial': [Errno -12269]
(SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.).
stuck: yes
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS
 Certificate
DB',pinfile='/etc/dirsrv/slapd-DNS-DOMAIN//pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=DNS-DOMAIN
subject: CN=ipa01.dns.domain,O=DNS-DOMAIN
expires: 2014-01-19 19:45:18 UTC
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes

However I cannot find the certificate that's expired?


Regards,
Siggi


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailm

Re: [Freeipa-users] Migration from OpenLDAP

[Dmitri Pal]

On 01/13/2014 10:24 AM, Petr Spacek wrote:
> On 13.1.2014 15:50, Alexander Bokovoy wrote:
>> On Mon, 13 Jan 2014, tizo wrote:
>>> Hi there,
>>>
>>> We have a working authentication system for GNU/Linux consisting in
>>> a Mit
>>> Kerberos Server, and an OpenLDAP directory with a particular
>>> structure. I
>>> was wondering if we could use Freeipa to administer those working
>>> components as they are, without having to deploy a new Freeipa
>>> server from
>>> scratch.
>> In short, no, it is not possible.
>
> I would like to elaborate this a bit more:
> You really can't use FreeIPA WebUI with home-grown LDAP+Kerberos
> system, but FreeIPA provides migrate-ds scripts which ease the
> transition from OpenLDAP.
>
> Please see
> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Migrating_from_a_Directory_Server_to_IPA.html
>
>
> You need to migrate OpenLDAP data to one FreeIPA server and then you
> can simply create FreeIPA server replicas as need.
>
> In other words, the migrate-ds script is run only once even if you
> have multiple servers with replicated data.
>
> There are some limited capabilities for migration with user passwords,
> but I will let other people to elaborate - this is not area of my
> expertise.

See the documentation about password migration. There are couple options.

>
> Let us know if you need any assistance during migration.
>


-- 
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] Certificate system unavailable

[Sigbjorn Lie]

On Mon, January 13, 2014 16:34, Rob Crittenden wrote:
> Sigbjorn Lie wrote:
>
>>
>>
>>
>> On Mon, January 13, 2014 15:58, Rob Crittenden wrote:
>>
>>> Sigbjorn Lie wrote:
>>>
>>>
 Hi,



 I seem to have issues with the certificate system on my IPA installation. 
 Looking up hosts
 in the IPA WEBUI on any of the IPA servers says "Certificate format error: 
 [Errno -8015]
 error (-8015)
 unknown".

 I also notice that hosts says the certificate system is unavailable.



 certmonger: Server failed request, will retry: 4301 (RPC failed at server. 
  Certificate
 operation cannot be completed: Failure decoding Certificate Signing 
 Request).


 Looking at the pki-ca logs on the ipa servers I see that some selftest 
 failed:



 # tail -100 selftests.log
 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: 
 Initializing self test
 plugins:
 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  
 loading all self test
 plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
 SelfTestSubsystem:
  loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 
 CET] [20] [1]
 SelfTestSubsystem:  loading all self test plugin
 instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
 SelfTestSubsystem:
 loading self test plugins in on-demand order 28697.main - 
 [13/Jan/2014:15:06:33 CET] [20]
 [1]
 SelfTestSubsystem:  loading self test plugins in
 startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
 SelfTestSubsystem: Self test
 plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 
 CET] [20] [1]
 SelfTestSubsystem: Running self test plugins
 specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 
 CET] [20] [1]
 CAPresence:
 CA is present
 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: 
 system certs
 verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] 
 SelfTestSubsystem: The
  CRITICAL self test plugin
 called selftests.container.instance.SystemCertsVerification running at 
 startup FAILED!

 the pki-cad service is running and "pki-cad status" displays the ports 
 available.
 /etc/init.d/pki-cad status
 pki-ca (pid 28697) is running...   [  OK  ]


 My main consern is that the certmonger requests for renew of certificates 
 for LDAP on 2 out
 of 3
 of the IPA servers has failed, and the current certificate is expiring the 
 19th of January,
 under a week from now.

 Do you have any suggestions to where I can start troubleshootng this issue?


>>>
>>> Check the trust on the audit certificate:
>>>
>>>
>>>
>>> # certutil -L -d /var/lib/pki-ca/alias/
>>> ...
>>> auditSigningCert cert-pki-ca u,u,Pu
>>>
>>> If the trust is not u,u,Pu then you can fix it with:
>>>
>>>
>>>
>>> # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca'
>>> -t u,u,Pu
>>>
>>>
>>>
>>> Then restart the CA and it should be ok.
>>>
>>>
>>
>> Looks like this certificate is expired. This is the same output on all 3 of 
>> the ipa servers.
>>
>>
>> How can this be fixed?
>>
>>
>>
>> # certutil -L -d /var/lib/pki-ca/alias/ -n "auditSigningCert cert-pki-ca"
>> Certificate:
>> Data:
>> Version: 3 (0x2)
>> Serial Number: 5 (0x5)
>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
>> Issuer: "CN=Certificate Authority,O=DNS.DOMAIN"
>> Validity:
>> Not Before: Thu Jan 19 19:44:24 2012
>> Not After : Wed Jan 08 19:44:24 2014
>>
>>
>>
>
> Go back in time to the 7th or 8th and run:
>
>
> # getcert resubmit -d /var/lib/pki-ca/alias -n "auditSigningCert
> cert-pki-ca"
>
> There may be other certs in a similar situation. getcert list will show you.
>
>

Ouch. That would be rather disruptive I suppose. There is quite a lot of 
activity going to this
server, not to mention it's the primary ntp and dns server for the network.

Do you suppose this todo list will work ?

Firewall off the rest of the network, leaving the ipa server alone
Stop ntpd
Set date to 8th of January
Run the getcert resubmit command.
Change date back to correct date
Start ntpd
Remove the firewall rules


How many of the services is required to be restarted for the renewal to work 
after the date is
changed to the 7th?


Regards,
Siggi


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

Re: [Freeipa-users] Certificate system unavailable

[Rob Crittenden]

Sigbjorn Lie wrote:




On Mon, January 13, 2014 15:58, Rob Crittenden wrote:

Sigbjorn Lie wrote:


Hi,


I seem to have issues with the certificate system on my IPA installation. 
Looking up hosts in
the IPA WEBUI on any of the IPA servers says "Certificate format error: [Errno 
-8015] error
(-8015)
unknown".

I also notice that hosts says the certificate system is unavailable.


certmonger: Server failed request, will retry: 4301 (RPC failed at server.  
Certificate
operation cannot be completed: Failure decoding Certificate Signing Request).


Looking at the pki-ca logs on the ipa servers I see that some selftest failed:


# tail -100 selftests.log
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: 
Initializing self test
plugins:
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  loading 
all self test
plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
SelfTestSubsystem:
loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 CET] 
[20] [1]
SelfTestSubsystem:  loading all self test plugin
instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
SelfTestSubsystem:  loading
self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 CET] 
[20] [1]
SelfTestSubsystem:  loading self test plugins in
startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
SelfTestSubsystem: Self test
plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 CET] 
[20] [1]
SelfTestSubsystem: Running self test plugins
specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] 
[20] [1] CAPresence:
CA is present
28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: 
system certs
verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] 
SelfTestSubsystem: The
CRITICAL self test plugin
called selftests.container.instance.SystemCertsVerification running at startup 
FAILED!

the pki-cad service is running and "pki-cad status" displays the ports 
available.
/etc/init.d/pki-cad status
pki-ca (pid 28697) is running...   [  OK  ]


My main consern is that the certmonger requests for renew of certificates for 
LDAP on 2 out of
3
of the IPA servers has failed, and the current certificate is expiring the 19th 
of January,
under a week from now.

Do you have any suggestions to where I can start troubleshootng this issue?



Check the trust on the audit certificate:


# certutil -L -d /var/lib/pki-ca/alias/
...
auditSigningCert cert-pki-ca u,u,Pu

If the trust is not u,u,Pu then you can fix it with:


# certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca'
-t u,u,Pu


Then restart the CA and it should be ok.



Looks like this certificate is expired. This is the same output on all 3 of the 
ipa servers.

How can this be fixed?


# certutil -L -d /var/lib/pki-ca/alias/ -n "auditSigningCert cert-pki-ca"
Certificate:
 Data:
 Version: 3 (0x2)
 Serial Number: 5 (0x5)
 Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
 Issuer: "CN=Certificate Authority,O=DNS.DOMAIN"
 Validity:
 Not Before: Thu Jan 19 19:44:24 2012
 Not After : Wed Jan 08 19:44:24 2014




Go back in time to the 7th or 8th and run:

# getcert resubmit -d /var/lib/pki-ca/alias -n "auditSigningCert 
cert-pki-ca"


There may be other certs in a similar situation. getcert list will show you.

rob

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

Re: [Freeipa-users] Migration from OpenLDAP

[Petr Spacek]

On 13.1.2014 15:50, Alexander Bokovoy wrote:

On Mon, 13 Jan 2014, tizo wrote:

Hi there,

We have a working authentication system for GNU/Linux consisting in a Mit
Kerberos Server, and an OpenLDAP directory with a particular structure. I
was wondering if we could use Freeipa to administer those working
components as they are, without having to deploy a new Freeipa server from
scratch.

In short, no, it is not possible.


I would like to elaborate this a bit more:
You really can't use FreeIPA WebUI with home-grown LDAP+Kerberos system, but 
FreeIPA provides migrate-ds scripts which ease the transition from OpenLDAP.


Please see
http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Migrating_from_a_Directory_Server_to_IPA.html

You need to migrate OpenLDAP data to one FreeIPA server and then you can 
simply create FreeIPA server replicas as need.


In other words, the migrate-ds script is run only once even if you have 
multiple servers with replicated data.


There are some limited capabilities for migration with user passwords, but I 
will let other people to elaborate - this is not area of my expertise.


Let us know if you need any assistance during migration.

--
Petr^2 Spacek

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

Re: [Freeipa-users] Certificate system unavailable

[Sigbjorn Lie]

On Mon, January 13, 2014 15:58, Rob Crittenden wrote:
> Sigbjorn Lie wrote:
>
>> Hi,
>>
>>
>> I seem to have issues with the certificate system on my IPA installation. 
>> Looking up hosts in
>> the IPA WEBUI on any of the IPA servers says "Certificate format error: 
>> [Errno -8015] error
>> (-8015)
>> unknown".
>>
>> I also notice that hosts says the certificate system is unavailable.
>>
>>
>> certmonger: Server failed request, will retry: 4301 (RPC failed at server.  
>> Certificate
>> operation cannot be completed: Failure decoding Certificate Signing Request).
>>
>>
>> Looking at the pki-ca logs on the ipa servers I see that some selftest 
>> failed:
>>
>>
>> # tail -100 selftests.log
>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: 
>> Initializing self test
>> plugins:
>> 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  loading 
>> all self test
>> plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
>> SelfTestSubsystem:
>> loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 
>> CET] [20] [1]
>> SelfTestSubsystem:  loading all self test plugin
>> instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
>> SelfTestSubsystem:  loading
>> self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 CET] 
>> [20] [1]
>> SelfTestSubsystem:  loading self test plugins in
>> startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
>> SelfTestSubsystem: Self test
>> plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 
>> CET] [20] [1]
>> SelfTestSubsystem: Running self test plugins
>> specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] 
>> [20] [1] CAPresence:
>> CA is present
>> 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: 
>> system certs
>> verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] 
>> SelfTestSubsystem: The
>> CRITICAL self test plugin
>> called selftests.container.instance.SystemCertsVerification running at 
>> startup FAILED!
>>
>> the pki-cad service is running and "pki-cad status" displays the ports 
>> available.
>> /etc/init.d/pki-cad status
>> pki-ca (pid 28697) is running...   [  OK  ]
>>
>>
>> My main consern is that the certmonger requests for renew of certificates 
>> for LDAP on 2 out of
>> 3
>> of the IPA servers has failed, and the current certificate is expiring the 
>> 19th of January,
>> under a week from now.
>>
>> Do you have any suggestions to where I can start troubleshootng this issue?
>>
>
> Check the trust on the audit certificate:
>
>
> # certutil -L -d /var/lib/pki-ca/alias/
> ...
> auditSigningCert cert-pki-ca u,u,Pu
>
> If the trust is not u,u,Pu then you can fix it with:
>
>
> # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca'
> -t u,u,Pu
>
>
> Then restart the CA and it should be ok.
>

Looks like this certificate is expired. This is the same output on all 3 of the 
ipa servers.

How can this be fixed?


# certutil -L -d /var/lib/pki-ca/alias/ -n "auditSigningCert cert-pki-ca"
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 5 (0x5)
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Issuer: "CN=Certificate Authority,O=DNS.DOMAIN"
Validity:
Not Before: Thu Jan 19 19:44:24 2012
Not After : Wed Jan 08 19:44:24 2014


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

Re: [Freeipa-users] Sudo rule processing order

[Martin Kosek]

Ok, that's up to your preference.

The hotfix below worked for me in my test environment and is pretty low risk.
But of course, it is not "RHEL rubber stamped". Eventually, you can evaluate
the fix yourself in a test environment.

HTH,
Martin

On 01/13/2014 02:41 PM, Fred van Zwieten wrote:
> Martin,
> 
> Sorry for the late reply.
> 
> Thanks for spotting this. I suspect I cannot "just" change ldap in our IPA.
> This is part of a production environment consisting solely of supported
> RHEL 6.4 servers. I can snapshot the IPA servers (they are VM's) to be able
> to roll back in case of trouble, but I am not sure such a change is
> "supported".
> 
> Fred
> 
> 
> On Fri, Jan 10, 2014 at 5:28 PM, Martin Kosek  wrote:
> 
>> Ah, I think I found the root cause. Our sudoers compat tree configuration
>> missed out the sudoOrder attribute. The order was thus missing in LDAP
>> sudoers
>> and thus ineffective. I filed an upstream ticket to fix it:
>> https://fedorahosted.org/freeipa/ticket/4107
>>
>> However, to hotfix it in your environment, could you try manually fixing
>> the
>> configuration on your FreeIPA server?
>>
>> $ ldapmodify -h `hostname` -D "cn=Directory Manager" -x -W
>> dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
>> changetype: modify
>> add: schema-compat-entry-attribute
>> schema-compat-entry-attribute: sudoOrder=%{sudoOrder}
>>
>>
>> This should do the trick.
>>
>> Martin
>>
>> On 01/10/2014 05:17 PM, Martin Kosek wrote:
>>> On 01/10/2014 04:52 PM, Fred van Zwieten wrote:
 Yes, you would expect that to help, wouldn't you :-)
>>>
>>> Yes, I would :-)
>>>

 Didn't even know this existed. Thanks for that.

 User has 3 sudo rules. I have set the allow_all rule to 1, the second
>> rule
 to 2 and the cobbler (with the "!authenticate" option) rule to 99:
>>>
>>> What is the version of the SUDO on your system? According to
>>> http://www.sudo.ws/sudoers.ldap.man.html
>>> it was implemented in SUDO 1.7.5.
>>>
>>> Martin
>>>

 User  may run the following commands on this host:
 (root) ALL
 (root) /bin/cat, /bin/egrep, /bin/find, /bin/grep, /bin/ls,
>> /bin/more,
 /usr/bin/less, !/bin/su
 (root) NOPASSWD: /usr/bin/cobbler
 (root) !/bin/su

 Nope. Didn't help.

 Fred

 On Fri, Jan 10, 2014 at 3:59 PM, Martin Kosek 
>> wrote:

> On 01/10/2014 11:52 AM, Fred van Zwieten wrote:
>> Hi,
>>
>> I have a sudo rule in IPA that has the !authenticate option added to
> enable
>> admins to execute certain programs as root without authentication.
>>
>> It doesn't work. There is another rule for the admins that allow all
>> commands as long as they give their password.
>>
>> In a sudoers file, you can solve this by specifing the nopasswd rule
>> as
>> last.
>>
>> sudo -l from an IPA-client gives me this:
>>
>> ***@svr001 ~]$ sudo -l
>> Matching Defaults entries for *** on this host:
>> requiretty, !visiblepw, always_set_home, env_reset,
>> env_keep="COLORS
>> DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS",
>> env_keep+="MAIL
> PS1
>> PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
>> env_keep+="LC_COLLATE
>> LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
>> env_keep+="LC_MONETARY
>> LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME
>> LC_ALL
>> LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
>> secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
>>
>> User  may run the following commands on this host:
>> (root) NOPASSWD: ALL
>> (root) /bin/cat, /bin/egrep, /bin/find, /bin/grep, /bin/ls,
> /bin/more,
>> /usr/bin/less, !/bin/su
>> (root) NOPASSWD: /usr/bin/cobbler
>> (root) !/bin/su
>>
>> I want the cobbler command to run without password authentication.
>> What
> am
>> I doing wrong?
>>
>
> Would setting SUDO rule order help?
>
> # ipa sudorule-mod -h
> ...
>   --order=INT   integer to order the Sudo rules
> ...
>
> Martin
>
>

>>>
>>
>>
> 

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

Re: [Freeipa-users] Certificate system unavailable

[Rob Crittenden]

Sigbjorn Lie wrote:

Hi,

Thank you for your prompt reply Rob.


On Mon, January 13, 2014 15:58, Rob Crittenden wrote:

Sigbjorn Lie wrote:


Hi,


I seem to have issues with the certificate system on my IPA installation. 
Looking up hosts in
the IPA WEBUI on any of the IPA servers says "Certificate format error: [Errno 
-8015] error
(-8015)
unknown".

I also notice that hosts says the certificate system is unavailable.


certmonger: Server failed request, will retry: 4301 (RPC failed at server.  
Certificate
operation cannot be completed: Failure decoding Certificate Signing Request).


Looking at the pki-ca logs on the ipa servers I see that some selftest failed:


# tail -100 selftests.log
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: 
Initializing self test
plugins:
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  loading 
all self test
plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
SelfTestSubsystem:
loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 CET] 
[20] [1]
SelfTestSubsystem:  loading all self test plugin
instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
SelfTestSubsystem:  loading
self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 CET] 
[20] [1]
SelfTestSubsystem:  loading self test plugins in
startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] 
SelfTestSubsystem: Self test
plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 CET] 
[20] [1]
SelfTestSubsystem: Running self test plugins
specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] 
[20] [1] CAPresence:
CA is present
28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: 
system certs
verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] 
SelfTestSubsystem: The
CRITICAL self test plugin
called selftests.container.instance.SystemCertsVerification running at startup 
FAILED!

the pki-cad service is running and "pki-cad status" displays the ports 
available.
/etc/init.d/pki-cad status
pki-ca (pid 28697) is running...   [  OK  ]


My main consern is that the certmonger requests for renew of certificates for 
LDAP on 2 out of
3
of the IPA servers has failed, and the current certificate is expiring the 19th 
of January,
under a week from now.

Do you have any suggestions to where I can start troubleshootng this issue?



Check the trust on the audit certificate:


# certutil -L -d /var/lib/pki-ca/alias/
...
auditSigningCert cert-pki-ca u,u,Pu


All the 3 ipa servers return u,u,Pu for auditSigningCert

# certutil -L -d /var/lib/pki-ca/alias/

Certificate Nickname Trust Attributes
  SSL,S/MIME,JAR/XPI

caSigningCert cert-pki-caCTu,Cu,Cu
Server-Cert cert-pki-ca  u,u,u
auditSigningCert cert-pki-ca u,u,Pu
ocspSigningCert cert-pki-ca  u,u,u
subsystemCert cert-pki-cau,u,u



If the trust is not u,u,Pu then you can fix it with:


# certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca'
-t u,u,Pu


Then restart the CA and it should be ok.



I have restarted the dirsrv for PKI-IPA, and the pki-cad service on all 3 IPA 
servers.



What is the status on the failed certmonger requests?


After I restarted dirsrv, pki-cad and then the httpd on ipa01 the status of the 
request is now:

Request ID '20120119194518':
status: CA_UNREACHABLE
ca-error: Server failed request, will retry: 907 (RPC failed at server. 
 cannot connect to
'https://ipa01.dns.domain:443/ca/agent/ca/displayBySerial': [Errno -12269]
(SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.).
stuck: yes
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS
 Certificate
DB',pinfile='/etc/dirsrv/slapd-DNS-DOMAIN//pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=DNS-DOMAIN
subject: CN=ipa01.dns.domain,O=DNS-DOMAIN
expires: 2014-01-19 19:45:18 UTC
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes

However I cannot find the certificate that's expired?


Can provide the output of getcert rather than ipa-getcert? It will show 
additional certificates that are issued/renewed outside of the IPA API.


rob

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

Re: [Freeipa-users] Certificate system unavailable

[Rob Crittenden]

Sigbjorn Lie wrote:

Hi,

I seem to have issues with the certificate system on my IPA installation. 
Looking up hosts in the
IPA WEBUI on any of the IPA servers says "Certificate format error: [Errno 
-8015] error (-8015)
unknown".

I also notice that hosts says the certificate system is unavailable.

  certmonger: Server failed request, will retry: 4301 (RPC failed at server.  
Certificate operation
cannot be completed: Failure decoding Certificate Signing Request).


Looking at the pki-ca logs on the ipa servers I see that some selftest failed:

# tail -100 selftests.log
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: 
Initializing self test plugins:
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  loading 
all self test plugin
logger parameters
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  loading 
all self test plugin
instances
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  loading 
all self test plugin
instance parameters
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  loading 
self test plugins in
on-demand order
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  loading 
self test plugins in
startup order
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Self test 
plugins have been
successfully loaded!
28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: Running 
self test plugins
specified to be executed at startup:
28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] CAPresence:  CA is present
28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: 
system certs
verification failure
28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: The 
CRITICAL self test plugin
called selftests.container.instance.SystemCertsVerification running at startup 
FAILED!

the pki-cad service is running and "pki-cad status" displays the ports 
available.
/etc/init.d/pki-cad status
pki-ca (pid 28697) is running...   [  OK  ]


My main consern is that the certmonger requests for renew of certificates for 
LDAP on 2 out of 3
of the IPA servers has failed, and the current certificate is expiring the 19th 
of January, under
a week from now.

Do you have any suggestions to where I can start troubleshootng this issue?


Check the trust on the audit certificate:

# certutil -L -d /var/lib/pki-ca/alias/
...
auditSigningCert cert-pki-ca u,u,Pu

If the trust is not u,u,Pu then you can fix it with:

# certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' 
-t u,u,Pu


Then restart the CA and it should be ok.

What is the status on the failed certmonger requests?

rob

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

Re: [Freeipa-users] About Freeipa

[Alexander Bokovoy]

On Mon, 13 Jan 2014, tizo wrote:

Hi there,

We have a working authentication system for GNU/Linux consisting in a Mit
Kerberos Server, and an OpenLDAP directory with a particular structure. I
was wondering if we could use Freeipa to administer those working
components as they are, without having to deploy a new Freeipa server from
scratch.

In short, no, it is not possible.


--
/ Alexander Bokovoy

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

[Freeipa-users] About Freeipa

[tizo]

Hi there,

We have a working authentication system for GNU/Linux consisting in a Mit
Kerberos Server, and an OpenLDAP directory with a particular structure. I
was wondering if we could use Freeipa to administer those working
components as they are, without having to deploy a new Freeipa server from
scratch.

Thanks,

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

[Freeipa-users] Certificate system unavailable

[Sigbjorn Lie]

Hi,

I seem to have issues with the certificate system on my IPA installation. 
Looking up hosts in the
IPA WEBUI on any of the IPA servers says "Certificate format error: [Errno 
-8015] error (-8015)
unknown".

I also notice that hosts says the certificate system is unavailable.

 certmonger: Server failed request, will retry: 4301 (RPC failed at server.  
Certificate operation
cannot be completed: Failure decoding Certificate Signing Request).


Looking at the pki-ca logs on the ipa servers I see that some selftest failed:

# tail -100 selftests.log
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: 
Initializing self test plugins:
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  loading 
all self test plugin
logger parameters
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  loading 
all self test plugin
instances
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  loading 
all self test plugin
instance parameters
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  loading 
self test plugins in
on-demand order
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem:  loading 
self test plugins in
startup order
28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Self test 
plugins have been
successfully loaded!
28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: Running 
self test plugins
specified to be executed at startup:
28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] CAPresence:  CA is present
28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: 
system certs
verification failure
28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: The 
CRITICAL self test plugin
called selftests.container.instance.SystemCertsVerification running at startup 
FAILED!

the pki-cad service is running and "pki-cad status" displays the ports 
available.
/etc/init.d/pki-cad status
pki-ca (pid 28697) is running...   [  OK  ]


My main consern is that the certmonger requests for renew of certificates for 
LDAP on 2 out of 3
of the IPA servers has failed, and the current certificate is expiring the 19th 
of January, under
a week from now.

Do you have any suggestions to where I can start troubleshootng this issue?


Regards,
Siggi


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

Re: [Freeipa-users] Sudo rule processing order

[Fred van Zwieten]

Martin,

Sorry for the late reply.

Thanks for spotting this. I suspect I cannot "just" change ldap in our IPA.
This is part of a production environment consisting solely of supported
RHEL 6.4 servers. I can snapshot the IPA servers (they are VM's) to be able
to roll back in case of trouble, but I am not sure such a change is
"supported".

Fred


On Fri, Jan 10, 2014 at 5:28 PM, Martin Kosek  wrote:

> Ah, I think I found the root cause. Our sudoers compat tree configuration
> missed out the sudoOrder attribute. The order was thus missing in LDAP
> sudoers
> and thus ineffective. I filed an upstream ticket to fix it:
> https://fedorahosted.org/freeipa/ticket/4107
>
> However, to hotfix it in your environment, could you try manually fixing
> the
> configuration on your FreeIPA server?
>
> $ ldapmodify -h `hostname` -D "cn=Directory Manager" -x -W
> dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
> changetype: modify
> add: schema-compat-entry-attribute
> schema-compat-entry-attribute: sudoOrder=%{sudoOrder}
>
>
> This should do the trick.
>
> Martin
>
> On 01/10/2014 05:17 PM, Martin Kosek wrote:
> > On 01/10/2014 04:52 PM, Fred van Zwieten wrote:
> >> Yes, you would expect that to help, wouldn't you :-)
> >
> > Yes, I would :-)
> >
> >>
> >> Didn't even know this existed. Thanks for that.
> >>
> >> User has 3 sudo rules. I have set the allow_all rule to 1, the second
> rule
> >> to 2 and the cobbler (with the "!authenticate" option) rule to 99:
> >
> > What is the version of the SUDO on your system? According to
> > http://www.sudo.ws/sudoers.ldap.man.html
> > it was implemented in SUDO 1.7.5.
> >
> > Martin
> >
> >>
> >> User  may run the following commands on this host:
> >> (root) ALL
> >> (root) /bin/cat, /bin/egrep, /bin/find, /bin/grep, /bin/ls,
> /bin/more,
> >> /usr/bin/less, !/bin/su
> >> (root) NOPASSWD: /usr/bin/cobbler
> >> (root) !/bin/su
> >>
> >> Nope. Didn't help.
> >>
> >> Fred
> >>
> >> On Fri, Jan 10, 2014 at 3:59 PM, Martin Kosek 
> wrote:
> >>
> >>> On 01/10/2014 11:52 AM, Fred van Zwieten wrote:
>  Hi,
> 
>  I have a sudo rule in IPA that has the !authenticate option added to
> >>> enable
>  admins to execute certain programs as root without authentication.
> 
>  It doesn't work. There is another rule for the admins that allow all
>  commands as long as they give their password.
> 
>  In a sudoers file, you can solve this by specifing the nopasswd rule
> as
>  last.
> 
>  sudo -l from an IPA-client gives me this:
> 
>  ***@svr001 ~]$ sudo -l
>  Matching Defaults entries for *** on this host:
>  requiretty, !visiblepw, always_set_home, env_reset,
> env_keep="COLORS
>  DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS",
> env_keep+="MAIL
> >>> PS1
>  PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
> env_keep+="LC_COLLATE
>  LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
> env_keep+="LC_MONETARY
>  LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME
> LC_ALL
>  LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
>  secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
> 
>  User  may run the following commands on this host:
>  (root) NOPASSWD: ALL
>  (root) /bin/cat, /bin/egrep, /bin/find, /bin/grep, /bin/ls,
> >>> /bin/more,
>  /usr/bin/less, !/bin/su
>  (root) NOPASSWD: /usr/bin/cobbler
>  (root) !/bin/su
> 
>  I want the cobbler command to run without password authentication.
> What
> >>> am
>  I doing wrong?
> 
> >>>
> >>> Would setting SUDO rule order help?
> >>>
> >>> # ipa sudorule-mod -h
> >>> ...
> >>>   --order=INT   integer to order the Sudo rules
> >>> ...
> >>>
> >>> Martin
> >>>
> >>>
> >>
> >
>
>
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] CA setup and ipa-gertcert questions

[Martin Kosek]

On 01/13/2014 12:53 AM, Charlie Derwent wrote:
> On Sun, Jan 12, 2014 at 11:01 PM, Dmitri Pal  wrote:
> 
>>  On 01/11/2014 09:20 AM, Charlie Derwent wrote:
>>
>>  Hi
>>
>>  I'm experiencing an issue trying to use ipa-getcert on my IPA clients.
>>
>>  When I run a command similar to this
>> ipa-getcert request -K principal/`hostname` -D `hostname` \
>>  -k /var/lib/ssl/private_keys/`hostname`.pem \
>>  -f /var/lib/ssl/certs/`hostname`.pem
>>
>>  Sometimes it will work, but 9 times out of 10 an "ipa-getcert list" will
>> show the request failed with a status of CA_UNREACHABLE. I'm fairly certain
>> it's not a time related issue as I tend to run the command just after
>> enrolment and our NTP servers are rock solid.
>>
>>  Now please correct me if I'm wrong (because it feels like I
>> am wrong) but I think this is happening because not all of my replicas are
>> Certificate Authorities but the clients are still trying to validate their
>> certificate signing requests with them.
>>
>>  Am I mistaken? Have I misconfigured something? If my theory is
>> correct is there a way to force the client to only talk to the replica(s)
>> running the CA service for these types of tasks?
>>
>>  Anyway to try and get round the issue I decided to try and make all my
>> IPA replicas Certificate Authorities and ran into the issue linked below
>>
>>  Bug 905064 - ipa install error Unable to find preop.pin
>> https://bugzilla.redhat.com/show_bug.cgi?id=905064
>>
>>  This has stopped me from rolling out the CA functionality across all of
>> my replicas (and I almost trashed a replica in the process of trying to
>> work around it).
>>
>>  I'm not really bothered which way I go about solving the problem but
>> would really appreciate some assistance as it feels like I'm stuck between
>> a rock and a hard place.
>>
>>  Thanks,
>> Charlie
>>
>>
>>
>>
>> ___
>> Freeipa-users mailing 
>> listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users
>>
>>
>> Even if the replica does not have CA it has code to turn around and proxy
>> request to the corresponding replica that has CA.
>> The first thing to check is the logs on the certmonger side that does the
>> certificate request to see which replica it is trying to connect and httpd
>> logs from the replica it tries to hit. If the requests do not hit (which I
>> suspect the case since the client returned CA_UNREACHABLE) then it might be
>> a firewall issue between the client and the replica. If it hits the server
>> but server fails to proxy and returns CA_UNREACHABLE to the client then it
>> is probably a FW issue between replicas.
>>
>> At least this is where I would dig.
>>
>> Also the bug you mentioned is a race condition and seems like a rare one
>> so there is a chance it would not happen all the time if you try more than
>> once or may be choose a different system.
>> Do you hit every time you try?
>>
>> --
>> 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
>>
> 
> Thanks for the tips regarding the CA authorization chain I'll try to take a
> closer log at the logs now I know what I'm looking for.
> 
> Regarding the replica CA setup, once the installation failed the first time
> I didn't get another chance. No matter what I did the replica was convinced
> there was another CA already installed. I even resorted to uninstalling the
> replica completely by running "ipa-setup-install --uninstall" a few times
> consecutively to make sure everything was gone but whenever I tried to
> re-install adding the --setup-ca option it didn't work.
> 
> I assumed there was a file or a service I had to stop or remove to get it
> going again so when I found this bug here
> https://bugzilla.redhat.com/show_bug.cgi?id=953488 I followed Tomas' steps
> in comment 4, not all the paths were the same (differences between  IPA
> 3.0.0 and 3.2.0 I assume) but still no success.
> 
> In the end dropping the --setup-ca option and reinstalling got me back to
> where I had left off.
> 
> Was there a file/service I missed? I appreciate the help.
> Thanks
> Charlie

It is hard to tell what went wrong without logs from ipareplica-install.log or 
PKI.

But I would guess that the failed PKI instance is still here and not being
uninstalled by IPA uninstaller. Tomas' instructions were for Dogtag 10 based
CA, while you seem to use Dogtag 9. You can try uninstalling the Dogtag 9 based
CA instance with following command run on the replica with broken CA (if it is
still there):

# /usr/bin/pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca 
--force

If that does not help, we would need the logs to continue investigating.

Martin

__