[Freeipa-users] Reinitializing replica fails?

2017-12-07 Thread Jonathan Kelley via FreeIPA-users 
ipa-server-4.5.0-21.el7.centos.2.2.x86_64
ipa-server-common-4.5.0-21.el7.centos.2.2.noarch

​I was getting this error in errors.log:

​ ​
Data required to update replica has been purged
​ ​
from the changelog. If the error persists the replica
​ ​
must be reinitialized.

​This has been known to fix the issue:


[root@auth2 /]# ipa-replica-manage re-initialize --from auth1.mydomain.com
--verbose
ipa: ERROR: DNS query for auth1.mydomain.com. A failed: Text input is
malformed.
Traceback (most recent call last):
  File "/sbin/ipa-replica-manage", line 1615, in 
main(options, args)
  File "/sbin/ipa-replica-manage", line 1530, in main
if (not test_connection(realm, host, options.nolookup) or
  File "/sbin/ipa-replica-manage", line 142, in test_connection
enforce_host_existence(host)
  File "/sbin/ipa-replica-manage", line 840, in enforce_host_existence
verify_host_resolvable(host)
  File "/usr/lib/python2.7/site-packages/ipalib/util.py", line 91, in
verify_host_resolvable
raise errors.DNSResolverError(exception=ex)
DNSResolverError: Text input is malformed.
Unexpected error: Text input is malformed.

​I assumed I had a DNS issue, but can't seem to find one unless PTR records
are broken.

[root@auth2 /]# nslookup auth1.mydomain.com
Server: 127.0.0.1
Address: 127.0.0.1#53

Name: auth1.mydomain.com
Address: 192.168.0.33


[root@auth2 /]# dig auth1.mydomain.com @127.0.0.1

; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7 <<>> auth1.mydomain.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 433
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;auth1.mydomain.com. IN A

;; ANSWER SECTION:
auth1.mydomain.com. 1200 IN A 192.168.0.33


Do I just need to build a new replica and forget this one?​

-- 
 

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error, please notify the system manager. 
Please note that any views or opinions presented in this email are solely 
those of the author and do not necessarily represent those of the company. 
Finally, the recipient should check this email and any attachments for the 
presence of viruses. The company accepts no liability for any damage caused 
by any virus transmitted by this email.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] IPa and automount

2017-12-07 Thread Miguel Angel Coa M. via FreeIPA-users 
Hello,
I'm configure automount/nfs in my IPA server but a have a question for
change the remote mount point. For example, now the when user login
automount "mount" the home under /home/ , but i need change this
directory, for example /home/remote/

Example:

[.]
su - foo
df -h
ipa.example.local:/autohome/foo  8.0G  6.2G  1.9G  77% /home/foo
[.]


But i need

[.]
su - foo
df -h
ipa.example.local:/autohome/foo  8.0G  6.2G  1.9G  77% /home/remote/foo
[.]


My setting are:

ipa automountlocation-add ipauserhome
ipa automountmap-add ipauserhome auto.home
ipa automountkey-add ipauserhome auto.home --key="*" --info="-fstype=nfs
ipa.example.local:/autohome/&"
ipa automountlocation-tofiles  ipauserhome

Thanks

Saludos.
---
Miguel Coa M.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore

2017-12-07 Thread Harald Dunkel via FreeIPA-users 

Hi Flo and Andrew,

thanx for you replies, but I think you missed the point:

The new (external) root CA certificate and the new ipa
CA certificate are *in* freeipa already, but on the host
I had used for running ipa-cacert-manage to deploy this
new PKI the database in /var/lib/pki/pki-tomcat/ca/alias
appears to be in an inconsistent state. Manually fixing
this is not persistent.

If I create another CA replica, then this server looks
fine, except for the old root CA still in /etc/ipa/ca.crt .

I would like to get rid of the old PKI completely.


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore

2017-12-07 Thread Harald Dunkel via FreeIPA-users 

Hi Rob,

On 12/6/17 9:56 PM, Rob Crittenden via FreeIPA-users wrote:

Harald Dunkel via FreeIPA-users wrote:


Here is what I see on the broken ipa server:


[root@ipa1 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias

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

Server-Cert cert-pki-ca  u,u,u
subsystemCert cert-pki-cau,u,u
caSigningCert cert-pki-caCTu,Cu,Cu
auditSigningCert cert-pki-ca u,u,Pu
ocspSigningCert cert-pki-ca  u,u,u
CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C
CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE  ,,


The CN=example Root CA,... certificate is unwanted. It did not expire,
but it uses an invalid format for its expiration date. I ran ipa-cacert-manage
to replace it with the CN=root-CA,... certificate a few months ago.


The certificate database on another ipa server (not broken yet, as it
seems) looks different:


[root@ipa2 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias

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

caSigningCert cert-pki-caCTu,Cu,Cu
subsystemCert cert-pki-cau,u,u
CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C
caSigningCert cert-pki-caCTu,Cu,Cu
CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE  C,,
ocspSigningCert cert-pki-ca  u,u,u
auditSigningCert cert-pki-ca u,u,Pu
Server-Cert cert-pki-ca  u,u,u


I would highly appreciate any advice how to cleanup this mess.

How comes that the unwanted "example Root CA" is still in the databases at
all? Due to the broken format I have to get rid of it asap.


What is broken about the cert? I can only assume you installed your IPA
server by having an external CA sign it. It would appear that this
external CA, in your case CN=root-ca, isn't trusted hence the server
won't start.


The first ipa server was setup using an existing private PKI, managed
outside of freeipa. The root ca cert had a problem I noticed too late:
It uses an invalid format for the notAfter attribute. openssl is fine
with this format, but libressl on OpenBSD (and probably MacOS) rejects
it. See this thread for more information:

https://marc.info/?l=libressl=148939571912276=2

Point is, I had to create a new private PKI with a valid notAfter
attribute format, and to tell freeipa. I had used ipa-cacert-manage
to fix, following the guidelines on 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/cert-renewal.html#manual-cert-renewal-ext

ipa-cacert-manage renew --external-ca
:
ipa-cacert-manage renew --external-cert-file=/tmp/cert.pem 
--external-cert-file=/tmp/cacert.pem
ipa-certupdate
:
getcert list
getcert list | egrep Request\|CA\|issuer\|subject\|expires
:
ipa-getcert resubmit -i $request_id
:

So how comes that the new root certificate is not trusted?



To fix this you could run:

# certutil -M -d /var/lib/pki/pki-tomcat/ca/alias -n
"CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE" -t C,,



Done. ipa1 starts again. But this is not sufficient. If I run
ipa-certupdate, then the database is set back to the bad state.
/etc/ipa/ca.crt and /usr/share/ipa/html/ca.crt are still bad, too.

???


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore

2017-12-07 Thread Harald Dunkel via FreeIPA-users 

On 12/7/17 2:53 PM, Florence Blanc-Renaud wrote:


Hi,

if you run:

ipa-cacert-manage install -t C,, 
ipa-certupdate

then the new root certificate will be installed in all the required NSS 
databases. Do not forget to run ipa-certupdate on all the FreeIPA machines.



This did not work:

[root@ipa1 ~]# ipa-cacert-manage install -t C,, pki2/root-ca.crt
Installing CA certificate, please wait
Not a valid CA certificate: (SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate 
issuer has been marked as not trusted by the user. (visit 
http://www.freeipa.org/page/Troubleshooting for troubleshooting guide)
The ipa-cacert-manage command failed.



Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Change default ldap scheme

2017-12-07 Thread Andrew Radygin via FreeIPA-users 
Anyone?
Of course this kind R question, but anyway I need to know.


2017-12-06 17:15 GMT+03:00 Andrew Radygin via FreeIPA-users <
freeipa-users@lists.fedorahosted.org>:

> Hello everybody,
>
> I want to know, is there possibility to change default ldap scheme, where
> user and groups are storing.
> For instance, I have:
>
> cn=USER, cn=groups, cn=accounts, dc=domain,dc=net
> cn=GROUP-OF-USERS, cn=groups, cn=accounts, dc=domain,dc=net
>
> It seems to be too straightforward. Can I change it to
> cn=USER, cn=groups, cn=accounts, dc=domain,dc=net
> cn=GROUP-OF-USERS, cn=org-groups, cn=accounts, dc=domain,dc=net
>
> ?
>
> Or to do any other corrections of ldap scheme for placing different
> objects.
>
> Thanks!
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>



-- 
Best regards, Andrew.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore

2017-12-07 Thread Harald Dunkel via FreeIPA-users 

PS: I have derived another CA replica "ipa0" from ipa2.
certutil shows different trustargs again. Shouldn't ipa2
and the new ipa0 have identical trustargs?

[root@ipa0 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias

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

caSigningCert cert-pki-caCTu,Cu,Cu
subsystemCert cert-pki-cau,u,u
Server-Cert cert-pki-ca  u,u,u
CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C
CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE  CT,C,C
caSigningCert cert-pki-caCTu,Cu,Cu
ocspSigningCert cert-pki-ca  u,u,u
auditSigningCert cert-pki-ca u,u,Pu


ipa2 has:

[root@ipa2 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias

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

caSigningCert cert-pki-caCTu,Cu,Cu
subsystemCert cert-pki-cau,u,u
CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE CT,C,C
caSigningCert cert-pki-caCTu,Cu,Cu
CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE  C,,
ocspSigningCert cert-pki-ca  u,u,u
auditSigningCert cert-pki-ca u,u,Pu
Server-Cert cert-pki-ca  u,u,u



Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Change default ldap scheme

2017-12-07 Thread Alexander Bokovoy via FreeIPA-users 

On to, 07 joulu 2017, Rob Crittenden via FreeIPA-users wrote:

Andrew Radygin via FreeIPA-users wrote:

Anyone?
Of course this kind R question, but anyway I need to know.


2017-12-06 17:15 GMT+03:00 Andrew Radygin via FreeIPA-users
>:

Hello everybody,

I want to know, is there possibility to change default ldap scheme,
where user and groups are storing.
For instance, I have:

cn=USER, cn=groups, cn=accounts, dc=domain,dc=net
cn=GROUP-OF-USERS, cn=groups, cn=accounts, dc=domain,dc=net

It seems to be too straightforward. Can I change it to
cn=USER, cn=groups, cn=accounts, dc=domain,dc=net
cn=GROUP-OF-USERS, cn=org-groups, cn=accounts, dc=domain,dc=net

?

Or to do any other corrections of ldap scheme for placing different
objects.


You could use slapi-nis to create your own compat area and format things
as you like but there is no way other than changing code to do this
otherwise. The containers are defined in one place but it wouldn't
surprise me if there are corner cases.

Yep. Whole IPA is built around idea of flat subtrees per object type, so
there are no organizational containers under cn=users or cn=groups or
cn=machines, etc.
--
/ Alexander Bokovoy
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore

2017-12-07 Thread Florence Blanc-Renaud via FreeIPA-users 

On 12/07/2017 09:17 AM, Harald Dunkel via FreeIPA-users wrote:

Hi Rob,

On 12/6/17 9:56 PM, Rob Crittenden via FreeIPA-users wrote:

Harald Dunkel via FreeIPA-users wrote:


Here is what I see on the broken ipa server:


[root@ipa1 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias

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


Server-Cert cert-pki-ca  u,u,u
subsystemCert cert-pki-ca    u,u,u
caSigningCert cert-pki-ca    CTu,Cu,Cu
auditSigningCert cert-pki-ca u,u,Pu
ocspSigningCert cert-pki-ca  u,u,u
CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE 
CT,C,C

CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE  ,,


The CN=example Root CA,... certificate is unwanted. It did not expire,
but it uses an invalid format for its expiration date. I ran 
ipa-cacert-manage

to replace it with the CN=root-CA,... certificate a few months ago.


The certificate database on another ipa server (not broken yet, as it
seems) looks different:


[root@ipa2 ~]# certutil -L -d /var/lib/pki/pki-tomcat/ca/alias

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


caSigningCert cert-pki-ca    CTu,Cu,Cu
subsystemCert cert-pki-ca    u,u,u
CN=example Root CA,OU=example Certificate Authority,O=example AG,C=DE 
CT,C,C

caSigningCert cert-pki-ca    CTu,Cu,Cu
CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE  C,,
ocspSigningCert cert-pki-ca  u,u,u
auditSigningCert cert-pki-ca u,u,Pu
Server-Cert cert-pki-ca  u,u,u


I would highly appreciate any advice how to cleanup this mess.

How comes that the unwanted "example Root CA" is still in the 
databases at

all? Due to the broken format I have to get rid of it asap.


What is broken about the cert? I can only assume you installed your IPA
server by having an external CA sign it. It would appear that this
external CA, in your case CN=root-ca, isn't trusted hence the server
won't start.


The first ipa server was setup using an existing private PKI, managed
outside of freeipa. The root ca cert had a problem I noticed too late:
It uses an invalid format for the notAfter attribute. openssl is fine
with this format, but libressl on OpenBSD (and probably MacOS) rejects
it. See this thread for more information:

 https://marc.info/?l=libressl=148939571912276=2

Point is, I had to create a new private PKI with a valid notAfter
attribute format, and to tell freeipa. I had used ipa-cacert-manage
to fix, following the guidelines on 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/cert-renewal.html#manual-cert-renewal-ext 



 ipa-cacert-manage renew --external-ca
 :
 ipa-cacert-manage renew --external-cert-file=/tmp/cert.pem 
--external-cert-file=/tmp/cacert.pem

 ipa-certupdate
 :
 getcert list
 getcert list | egrep Request\|CA\|issuer\|subject\|expires
 :
 ipa-getcert resubmit -i $request_id
 :

So how comes that the new root certificate is not trusted?



Hi,

if you run:

ipa-cacert-manage install -t C,, 
ipa-certupdate

then the new root certificate will be installed in all the required NSS 
databases. Do not forget to run ipa-certupdate on all the FreeIPA machines.


HTH,
Flo.



To fix this you could run:

# certutil -M -d /var/lib/pki/pki-tomcat/ca/alias -n
"CN=root-CA,OU=example Certificate Authority,O=example AG,C=DE" -t C,,



Done. ipa1 starts again. But this is not sufficient. If I run
ipa-certupdate, then the database is set back to the bad state.
/etc/ipa/ca.crt and /usr/share/ipa/html/ca.crt are still bad, too.

???


Regards
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Maintenance mode

2017-12-07 Thread Rob Crittenden via FreeIPA-users 
Lachlan Musicman via FreeIPA-users wrote:
> Stupid question, but to stop anyone from logging in anywhere - for
> instance during a maintenance period - is there an easy maintenance mode
> in IPA?
> 
> Or is the best method to disable all HBAC rules?

I guess it depends on what maintenance you're talking about, and where.

If it's general maintenance in your infrastructure then yeah, HBAC rules
seems a good place to start. I guess just leave one rule active, the
rule that lets the administrators log in.

There is no knob in IPA to do this.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: worst nightmare come true: ipa service doesn't start anymore

2017-12-07 Thread Andrew Radygin via FreeIPA-users 
Harald,
Maybe in the ldap certificate container you already have the same
certificate you're trying to install, but it has another key or untrusted?
Then try to delete it via ldapdelete and certutil -d and then try again
install new one.

2017-12-07 17:20 GMT+03:00 Harald Dunkel via FreeIPA-users <
freeipa-users@lists.fedorahosted.org>:

> On 12/7/17 2:53 PM, Florence Blanc-Renaud wrote:
>
>>
>> Hi,
>>
>> if you run:
>>
>> ipa-cacert-manage install -t C,, 
>> ipa-certupdate
>>
>> then the new root certificate will be installed in all the required NSS
>> databases. Do not forget to run ipa-certupdate on all the FreeIPA machines.
>>
>>
> This did not work:
>
> [root@ipa1 ~]# ipa-cacert-manage install -t C,, pki2/root-ca.crt
> Installing CA certificate, please wait
> Not a valid CA certificate: (SEC_ERROR_UNTRUSTED_ISSUER) Peer's
> certificate issuer has been marked as not trusted by the user. (visit
> http://www.freeipa.org/page/Troubleshooting for troubleshooting guide)
> The ipa-cacert-manage command failed.
>
>
>
>
> Regards
> Harri
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>



-- 
Best regards, Andrew.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Change default ldap scheme

2017-12-07 Thread Andrew Radygin via FreeIPA-users 
I see, thanks for the information.

2017-12-07 16:52 GMT+03:00 Alexander Bokovoy :

> On to, 07 joulu 2017, Rob Crittenden via FreeIPA-users wrote:
>
>> Andrew Radygin via FreeIPA-users wrote:
>>
>>> Anyone?
>>> Of course this kind R question, but anyway I need to know.
>>>
>>>
>>> 2017-12-06 17:15 GMT+03:00 Andrew Radygin via FreeIPA-users
>>> >> >:
>>>
>>> Hello everybody,
>>>
>>> I want to know, is there possibility to change default ldap scheme,
>>> where user and groups are storing.
>>> For instance, I have:
>>>
>>> cn=USER, cn=groups, cn=accounts, dc=domain,dc=net
>>> cn=GROUP-OF-USERS, cn=groups, cn=accounts, dc=domain,dc=net
>>>
>>> It seems to be too straightforward. Can I change it to
>>> cn=USER, cn=groups, cn=accounts, dc=domain,dc=net
>>> cn=GROUP-OF-USERS, cn=org-groups, cn=accounts, dc=domain,dc=net
>>>
>>> ?
>>>
>>> Or to do any other corrections of ldap scheme for placing different
>>> objects.
>>>
>>
>> You could use slapi-nis to create your own compat area and format things
>> as you like but there is no way other than changing code to do this
>> otherwise. The containers are defined in one place but it wouldn't
>> surprise me if there are corner cases.
>>
> Yep. Whole IPA is built around idea of flat subtrees per object type, so
> there are no organizational containers under cn=users or cn=groups or
> cn=machines, etc.
> --
> / Alexander Bokovoy
>



-- 
Best regards, Andrew.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org