Re: [Freeipa-users] deleting ipa user
On 04/29/2015 07:15 PM, Andy Thompson wrote: -Original Message- From: thierry bordaz [mailto:tbor...@redhat.com] Sent: Wednesday, April 29, 2015 1:07 PM To: Andy Thompson Cc: Ludwig Krispenz; Martin Kosek; freeipa-users@redhat.com Subject: Re: [Freeipa-users] deleting ipa user On 04/29/2015 06:45 PM, Andy Thompson wrote: -Original Message- From: thierry bordaz [mailto:tbor...@redhat.com] Sent: Wednesday, April 29, 2015 12:28 PM To: Andy Thompson Cc: Ludwig Krispenz; Martin Kosek; freeipa- us...@redhat.com mailto:freeipa-users@redhat.com Subject: Re: [Freeipa-users] deleting ipa user On 04/29/2015 05:58 PM, Andy Thompson wrote: dn: nsuniqueid=7e1a1f87-e82611e4- 99f1b343- f0abc1a8,cn=username,cn=groups,c n=accounts,dc=mhbenp,dc=lin nscpentrywsi: dn: nsuniqueid=7e1a1f87-e82611e4- 99f1b343- f0abc1a8,cn=username,cn=groups,c n=accounts,dc=mhbenp,dc=lin nscpentrywsi: objectClass;vucsn- 55364a4200050004: posixgroup nscpentrywsi: objectClass;vucsn- 55364a4200050004: ipaobject nscpentrywsi: objectClass;vucsn- 55364a4200050004: mepManagedEntry nscpentrywsi: objectClass;vucsn- 55364a4200050004: top nscpentrywsi: objectClass;vucsn- 5540deb800030003: nsTombstone nscpentrywsi: cn;vucsn- 55364a4200050004;mdcsn- 55364a4200050004: gfeigh nscpentrywsi: gidNumber;vucsn- 55364a4200050004: 124903 nscpentrywsi: description;vucsn- 55364a4200050004: User private group for username nscpentrywsi: mepManagedBy;vucsn- 55364a4200050004: uid= username,cn=users,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: creatorsName;vucsn- 55364a4200050004: cn=Managed Entries,cn=plugins,cn=config nscpentrywsi: modifiersName;vucsn- 55364a4200050004: cn=Managed Entries,cn=plugins,cn=config nscpentrywsi: createTimestamp;vucsn- 55364a4200050004: 20150421130152Z nscpentrywsi: modifyTimestamp;vucsn- 55364a4200050004: 20150421130152Z nscpentrywsi: nsUniqueId: 7e1a1f87- e82611e4- 99f1b343-f0abc1a8 nscpentrywsi: ipaUniqueID;vucsn- 55364a4200050004: 94dc1638-e826-11e4-878a- 005056a92af3 nscpentrywsi: parentid: 4 nscpentrywsi: entryid: 385 nscpentrywsi: nsParentUniqueId: 3763f193- e76411e4-99f1b343-f0abc1a8 nscpentrywsi: nstombstonecsn: 5540deb800030003 nscpentrywsi: nscpEntryDN: cn=username,cn=groups,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: entryusn: 52327 thought I tried that before, apparently not. ok, so we have the entry on one server, the csn of the objectclass: tombstone is : objectClass;vucsn-5540deb800030003: nsTombstone , which matches the csn in the error log: Consumer failed to replay change (uniqueid 7e1a1f87- e82611e4-99f1b343- f0abc1a8, CSN 5540deb800030003): Operations error (1) so the state of the entry is as expected. Now we nend to find it on the other server. If the
Re: [Freeipa-users] Web ui error “Your session has expired. Please re-login.” from a browser on a remote client.
On 04/25/2015 02:58 AM, Christopher Lamb wrote:
Hi All
I too am suffering from the infamous Web ui error “Your session has
expired. Please re-login.” using from browser(s) on remote client(s),
similar to the existing tickets:
https://www.redhat.com/archives/freeipa-users/2015-March/msg00211.html
https://www.redhat.com/archives/freeipa-users/2015-February/msg00315.html
https://www.redhat.com/archives/freeipa-users/2015-April/msg00047.html
We have 2 FreeIPA installations:
An “Old”, soon to be decommissioned v3.0.0, on OEL 6.5
The “new” instance, v4.1.0, on a fresh install of OEL 7.0
The error occurs on both instances.
I get the error from OSX and Windows clients (Firefox, Chrome, Safar,i IE
etc)
Very sporadically one of the above browsers will “let me in” - If I cycle
through all the browsers on various workstations / laptops on my desk
somtimes I get lucky and one will work.
kinit in a ssh session works.
SELinux is disabled.
All IPA Services are running.
I can find no error(s) in /var/log/httpd/error_log
In /var/log/krb5kdc.log I get entries like:
Apr 25 02:17:44 ldap2.xxx-xx.xx.xx.com krb5kdc[1933](info): TGS_REQ (6
etypes {18 17 16 23 25 26}) 9.159.8.200: ISSUE: authtime 1429921064, etypes
{rep=18 tkt=18 ses=18}, y...@xxx-xx.xx.xx.com for
HTTP/bsc-ldap2.xxx-xx.xx.xxx@xxx-xx.xx.xxx.com
Apr 25 02:17:44 ldap2.xxx-xx.xx.xxx.com krb5kdc[1933](info): closing down
fd 12
If I enter a wrong password, I correctly get “The password or username you
entered is incorrect. “, + errors in /var/log/httpd/error_log
None of the browsers have a krb5 ticket installed.
I get the error with both my user, and the default admin user.
From the same browsers I can successfully access the Web UI of the public
demo on https://ipa.demo1.freeipa.org/ipa/ui/
Do the machines with browsers have synchronized time with IPA servers?
If a client machine with browser is 20min+ in a future compared to IPA
server, the browser will treat ipa_session cookie as expired because its
validity is auth_time + 20 min.
Could you enable server debug logging [1] and send me entries from
httpd/error_log and krb5kdc.log which were added upon Web UI forms-based
auth with correct username and password?
[1]
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/server-config.html#server-debug
--
Petr Vobornik
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] PWM and IPA
On 04/30/2015 05:30 AM, Janelle wrote: Hi all, Just wondering if anyone has put together a guide for integrating PWM with IPA? I know there is a section on 389-ds, but that is kind of raw-389 and not the highly modified-for-IPA 389-ds. I would like to set this up for my users, but really don't want to do it using that guide unless that is what others might suggest? Any suggestions? We have this page with our take on self-service password reset: https://www.freeipa.org/page/Self-Service_Password_Reset And we also have a ticket for implementing pwm-like capability in FreeIPA: https://fedorahosted.org/freeipa/ticket/3611 This ticket may be worked on in near future, we have a candidate for the work. You may add yourself to CC of this ticket if you are interested for updates. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] deleting ipa user
You got a first replica where you failed to delete the entry. You got a second replica where you succeeded to delete the entry. On first replica you can see messages like: [29/Apr/2015:07:21:32 -0400] ldbm_back_delete - conn=0 op=0 Turning a tombstone into a tombstone! nsuniqueid=7e1a1f87-e82611e4-99f1b343- f0abc1a8,cn=username,cn=groups,cn=accounts,dc=domain,dc=com; e: 0x7fcc84226070, cache_state: 0x0, refcnt: 1 On the second replica you can see messages like: [29/Apr/2015:09:35:40 -0400] NSMMReplicationPlugin - agmt=cn=meTomdhixnpipa01.domain.com (mdhixnpipa01:389): Consumer failed to replay change (uniqueid 7e1a1f87-e82611e4-99f1b343-f0abc1a8, CSN 5540deb800030003): Operations error (1). Will retry later. On the first replica, you had difficulties to retrieve the entry and finally had to remove 'nsuniqueid' from the filter to retrieve this entry dn: nsuniqueid=7e1a1f82-e82611e4-99f1b343- f0abc1a8,uid=username,cn=users,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: dn: nsuniqueid=7e1a1f82-e82611e4-99f1b343- f0abc1a8,uid=username,cn=users,cn=accounts,dc=mhbenp,dc=lin ... nscpentrywsi: objectClass;vucsn-5540deb80003: nsTombstone ... nscpentrywsi: nsUniqueId: 7e1a1f82-e82611e4-99f1b343-f0abc1a8 ... On the second replica you can the entry: dn: nsuniqueid=7e1a1f87-e82611e4-99f1b343- f0abc1a8,cn=username,cn=groups,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: dn: nsuniqueid=7e1a1f87-e82611e4-99f1b343- f0abc1a8,cn=username,cn=groups,cn=accounts,dc=mhbenp,dc=lin ... nscpentrywsi: objectClass;vucsn-5540deb800030003: nsTombstone ... nscpentrywsi: nsUniqueId: 7e1a1f87-e82611e4-99f1b343-f0abc1a8 Note that the entry retrieved on the first replica has nsuniqueid=7e1a1f82.. while the entry retrieved on the second replica has nsuniqueid=7e1a1f87 ... It differs '2' instead of '7'. So this is not the same entry (from replication point of view). The error reported in the first replica was about Turning a tombstone into a tombstone! nsuniqueid=7e1a1f87... The error reported in the second replica was also about Consumer failed to replay change (uniqueid 7e1a1f87... So I think the entry you dumped on the first replica is not (should not be) the one we are looking for. It appears that f82 is the user object and f87 is the group object. So you are right, I don't think f82 is what we were looking for, it just happened to have the username in it when I grepped without filtering the uniqueid. I'm not sure why it was having problems with the user group object, but I don't have individual group objects showing up for any local accounts I've created. All that being said, I put 389-ds-base-1.3.3.1-16.el7_1.x86_64 on the box yesterday and the error has not shown since. So I'm not sure if it was because of the minor upgrade or cycling the daemon. Is there any way to find the root cause of this? And is it normal that individual group objects are not created for users? I thought I remembered reading somewhere that they were derived and not static entries? The few accounts I have on there were created in the web interface, most of my users are all trust users. Although it could be two entries having the same DN but that was deleted, added and then deleted again. The difficulty is to retrieve it (on the first replica) as we cannot specify its 'nsuniqueid' to retrieve it. May be you can retrieve it with its ((objectclass=nstombstone)(ipauniqueid=94dc1638-e826-11e4-878a- 005056a92af3)) thanks thierry dn: nsuniqueid=7e1a1f82-e82611e4-99f1b343- f0abc1a8,uid=username,cn=users,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: dn: nsuniqueid=7e1a1f82-e82611e4-99f1b343- f0abc1a8,uid=username,cn=users,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: modifyTimestamp;adcsn- 5540be0c000200040002;vucsn-5540be0c000200040002: 20150429111607Z nscpentrywsi: modifiersName;adcsn-5540be0c000200040001;vucsn- 5540be0c000200040001: uid=admin,cn=users,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: nsAccountLock;adcsn-5540be0c00020004;vucsn- 5540be0c00020004: TRUE nscpentrywsi: krbLastSuccessfulAuth;adcsn- 5537c9b20003;vucsn-5537c9b20003: 20150422161526Z nscpentrywsi: memberOf;adcsn-5537c2f500040003;vucsn- 5537c2f500040003: cn=ipausers,cn=groups,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: memberOf;vucsn-5537c2f500040003: ipaUniqueID=3897c894-e764-11e4-b05b- 005056a92af3,cn=hbac,dc=mhbenp,dc=lin nscpentrywsi: ipaNTSecurityIdentifier;adcsn- 5537a1b1000300040001;vucsn-5537a1b1000300040001: S-1-5-21-1257946092- 587846975-4124201916-1003 nscpentrywsi: passwordGraceUserTime;adcsn- 553692040004;vucsn-553692040004: 0 nscpentrywsi: krbPasswordExpiration;adcsn- 5536920200040005;vucsn-5536920200040005: 20150720180532Z nscpentrywsi: userPassword;adcsn-5536920200040004;vucsn- 5536920200040004:
Re: [Freeipa-users] deleting ipa user
On 04/30/2015 12:41 PM, Andy Thompson wrote: You got a first replica where you failed to delete the entry. You got a second replica where you succeeded to delete the entry. On first replica you can see messages like: [29/Apr/2015:07:21:32 -0400] ldbm_back_delete - conn=0 op=0 Turning a tombstone into a tombstone! nsuniqueid=7e1a1f87-e82611e4-99f1b343- f0abc1a8,cn=username,cn=groups,cn=accounts,dc=domain,dc=com; e: 0x7fcc84226070, cache_state: 0x0, refcnt: 1 On the second replica you can see messages like: [29/Apr/2015:09:35:40 -0400] NSMMReplicationPlugin - agmt=cn=meTomdhixnpipa01.domain.com (mdhixnpipa01:389): Consumer failed to replay change (uniqueid 7e1a1f87-e82611e4-99f1b343-f0abc1a8, CSN 5540deb800030003): Operations error (1). Will retry later. On the first replica, you had difficulties to retrieve the entry and finally had to remove 'nsuniqueid' from the filter to retrieve this entry dn: nsuniqueid=7e1a1f82-e82611e4-99f1b343- f0abc1a8,uid=username,cn=users,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: dn: nsuniqueid=7e1a1f82-e82611e4-99f1b343- f0abc1a8,uid=username,cn=users,cn=accounts,dc=mhbenp,dc=lin ... nscpentrywsi: objectClass;vucsn-5540deb80003: nsTombstone ... nscpentrywsi: nsUniqueId: 7e1a1f82-e82611e4-99f1b343-f0abc1a8 ... On the second replica you can the entry: dn: nsuniqueid=7e1a1f87-e82611e4-99f1b343- f0abc1a8,cn=username,cn=groups,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: dn: nsuniqueid=7e1a1f87-e82611e4-99f1b343- f0abc1a8,cn=username,cn=groups,cn=accounts,dc=mhbenp,dc=lin ... nscpentrywsi: objectClass;vucsn-5540deb800030003: nsTombstone ... nscpentrywsi: nsUniqueId: 7e1a1f87-e82611e4-99f1b343-f0abc1a8 Note that the entry retrieved on the first replica has nsuniqueid=7e1a1f82.. while the entry retrieved on the second replica has nsuniqueid=7e1a1f87 ... It differs '2' instead of '7'. So this is not the same entry (from replication point of view). The error reported in the first replica was about Turning a tombstone into a tombstone! nsuniqueid=7e1a1f87... The error reported in the second replica was also about Consumer failed to replay change (uniqueid 7e1a1f87... So I think the entry you dumped on the first replica is not (should not be) the one we are looking for. It appears that f82 is the user object and f87 is the group object. So you are right, I don't think f82 is what we were looking for, it just happened to have the username in it when I grepped without filtering the uniqueid. I'm not sure why it was having problems with the user group object, but I don't have individual group objects showing up for any local accounts I've created. You are right. I think the private group of a user is/should be deleted at the same time when you delete a user. All that being said, I put 389-ds-base-1.3.3.1-16.el7_1.x86_64 on the box yesterday and the error has not shown since. So I'm not sure if it was because of the minor upgrade or cycling the daemon. The logs gave a lot of information but without a test case it could be difficult to identify the RC. Now as I mentioned I hit (with a non systematic test case) an other bug when deleting a user. It was impossible to remove the entry/group. In this bug I tested on standalone instance but on replicated topology I wonder if it could have the same symptom. Is there any way to find the root cause of this? And is it normal that individual group objects are not created for users? I thought I remembered reading somewhere that they were derived and not static entries? The few accounts I have on there were created in the web interface, most of my users are all trust users. Although it could be two entries having the same DN but that was deleted, added and then deleted again. The difficulty is to retrieve it (on the first replica) as we cannot specify its 'nsuniqueid' to retrieve it. May be you can retrieve it with its ((objectclass=nstombstone)(ipauniqueid=94dc1638-e826-11e4-878a- 005056a92af3)) thanks thierry dn: nsuniqueid=7e1a1f82-e82611e4-99f1b343- f0abc1a8,uid=username,cn=users,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: dn: nsuniqueid=7e1a1f82-e82611e4-99f1b343- f0abc1a8,uid=username,cn=users,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: modifyTimestamp;adcsn- 5540be0c000200040002;vucsn-5540be0c000200040002: 20150429111607Z nscpentrywsi: modifiersName;adcsn-5540be0c000200040001;vucsn- 5540be0c000200040001: uid=admin,cn=users,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: nsAccountLock;adcsn-5540be0c00020004;vucsn- 5540be0c00020004: TRUE nscpentrywsi: krbLastSuccessfulAuth;adcsn- 5537c9b20003;vucsn-5537c9b20003: 20150422161526Z nscpentrywsi: memberOf;adcsn-5537c2f500040003;vucsn- 5537c2f500040003: cn=ipausers,cn=groups,cn=accounts,dc=mhbenp,dc=lin nscpentrywsi: memberOf;vucsn-5537c2f500040003: ipaUniqueID=3897c894-e764-11e4-b05b- 005056a92af3,cn=hbac,dc=mhbenp,dc=lin
Re: [Freeipa-users] Web ui error “Your session has expired. Please re-login.” from a browser on a remote client.
Hi Petr
Thanks, we solved this issue and reported that back on this thread. The
troubleshooting guide has even been updated as a result.
https://www.redhat.com/archives/freeipa-users/2015-April/msg00605.html
Your suggestion has however hit the nail on the head - the problem was
clock skew between the Server hosting freeIPA and the workstations.
Ironically, before installing freeIPA server we had no clock skew -clients
and workstation clocks were with seconds. Post freeIPA install, the server
was suddenly 2 hours in the future.
This seems to be because freeIPA had replaced the ntpd server entries in
the ntp.conf file. After reverting to our standard ntp.conf for a vm and
restarting ntpd the clock-skew vanished, as did the Your session has been
expired error on the the Web UI.
The 2 hours time difference was probably a result of the difference between
UTC and European Summer Time. It will likely be familiar to anybody who has
configured FIX interfaces in Europe.
Chris
b.t.w, the above applies to our new 4.1.0 installation. We get the same
session has expired error from our 3.0.0 freeIPA installation that we
will decommission shortly. On that machine the cause is not clock-skew.
From: Petr Vobornik pvobo...@redhat.com
To: Christopher Lamb/Switzerland/IBM@IBMCH,
freeipa-users@redhat.com
Date: 30.04.2015 12:52
Subject:Re: [Freeipa-users] Web ui error “Your session has expired.
Please re-login.” from a browser on a remote client.
On 04/25/2015 02:58 AM, Christopher Lamb wrote:
Hi All
I too am suffering from the infamous Web ui error “Your session has
expired. Please re-login.” using from browser(s) on remote client(s),
similar to the existing tickets:
https://www.redhat.com/archives/freeipa-users/2015-March/msg00211.html
https://www.redhat.com/archives/freeipa-users/2015-February/msg00315.html
https://www.redhat.com/archives/freeipa-users/2015-April/msg00047.html
We have 2 FreeIPA installations:
An “Old”, soon to be decommissioned v3.0.0, on OEL 6.5
The “new” instance, v4.1.0, on a fresh install of OEL 7.0
The error occurs on both instances.
I get the error from OSX and Windows clients (Firefox, Chrome, Safar,i IE
etc)
Very sporadically one of the above browsers will “let me in” - If I cycle
through all the browsers on various workstations / laptops on my desk
somtimes I get lucky and one will work.
kinit in a ssh session works.
SELinux is disabled.
All IPA Services are running.
I can find no error(s) in /var/log/httpd/error_log
In /var/log/krb5kdc.log I get entries like:
Apr 25 02:17:44 ldap2.xxx-xx.xx.xx.com krb5kdc[1933](info): TGS_REQ (6
etypes {18 17 16 23 25 26}) 9.159.8.200: ISSUE: authtime 1429921064,
etypes
{rep=18 tkt=18 ses=18}, y...@xxx-xx.xx.xx.com for
HTTP/bsc-ldap2.xxx-xx.xx.xxx@xxx-xx.xx.xxx.com
Apr 25 02:17:44 ldap2.xxx-xx.xx.xxx.com krb5kdc[1933](info): closing down
fd 12
If I enter a wrong password, I correctly get “The password or username
you
entered is incorrect. “, + errors in /var/log/httpd/error_log
None of the browsers have a krb5 ticket installed.
I get the error with both my user, and the default admin user.
From the same browsers I can successfully access the Web UI of the public
demo on https://ipa.demo1.freeipa.org/ipa/ui/
Do the machines with browsers have synchronized time with IPA servers?
If a client machine with browser is 20min+ in a future compared to IPA
server, the browser will treat ipa_session cookie as expired because its
validity is auth_time + 20 min.
Could you enable server debug logging [1] and send me entries from
httpd/error_log and krb5kdc.log which were added upon Web UI forms-based
auth with correct username and password?
[1]
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/server-config.html#server-debug
--
Petr Vobornik
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
[Freeipa-users] RHEL5 clients not getting ssh key
Is there a trick to getting a users SSH key that’s attached to their FreeIPA account to work on RHEL 5 servers? users can ssh into the RHEL 6 clients with no issues but they still get prompted for their passwords on the RHEL 5 server, so it’s not pushing down their ssh keys. Thanks! Regards, -- Aric Wilisch awili...@gmail.com -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] thousands DSRetroclPlugin mesages
On 04/29/2015 05:51 PM, Martin (Lists) wrote: Am 29.04.2015 um 15:43 schrieb Ludwig Krispenz: On 04/29/2015 03:17 PM, Martin (Lists) wrote: Am 27.04.2015 um 09:45 schrieb Ludwig Krispenz: On 04/26/2015 10:49 AM, Martin (Lists) wrote: Hallo after a reboot I get almost thousand of the following messages: DSRetroclPlugin - delete_changerecord: could not delete change record 128755 (rc: 32) this message comes from changeglog trimming and means that an entry, which should be purged does not exist (any more). the retrocl maintains a first/lastchange and trinming starts at firstchange. if for some reason (race ?) there is an attempt to try to delete the same entry a second time this message should be logged. since the changenumbers in the error message increases, I think changelog trimming moves forward. you could do searches on cn=changelog to verify that trimming works. changelog is part of the ldbm database plugin and contains several informations I don't understand (or understand partially). What kind of information should I look for? the changelog keeps track of the changes applied to the database, a typical entry looks like: dn: changenumber=4,cn=changelog objectClass: top objectClass: changelogentry changeNumber: 4 targetDn: cn=tuser,ou=people,dc=example,dc=com changeTime: 20140411093444Z changeType: delete OK, I looked in the wrong directory. Now I have found many changelog entries, starting with number 152926 and ending with 155512 (ldapsearch states 2588 numEntries). Should that be that much? The oldest is about two days and an half old and it does not change within the last few minutes. each entry gets a DN made up from he changenumber, so your entries will be named: dn: changenumber=61,cn=changelog dn: changenumber=62,cn=changelog dn: changenumber=63,cn=changelog dn: changenumber=64,cn=changelog changenumbers start and are always incremented, changelog trimming removes old entries (depending on config). so if you do a search like: ldapsearch .. -b cn=changelog the changenumber of the first entry rerurne should always increase, indicating that trimming works. As it seems my trimming is broken, at least partially. Is there something I can adjust? no, it seems to be ok, IPA configures the changelog maxage as 2d, so if changelog trimming runs, it removes changes older than two days, then it sleeps for this time and then runs again, so the changes could pile up to four days, then get trimmed and so on ... you said thousands of messages, how frequent are they really ? On every reboot I got these messages. I do not get them during normal opperation. how frequently do you reboot ? maybe you only see the trimming after startup Something odd I observed after the last two reboots: ns-slapd runs my hard disk for several minutes (about 15 minutes) after the reboot. This is the time it takes to log all these change record messages. Kindly Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] deleting ipa user
It appears that f82 is the user object and f87 is the group object. So you are right, I don't think f82 is what we were looking for, it just happened to have the username in it when I grepped without filtering the uniqueid. I'm not sure why it was having problems with the user group object, but I don't have individual group objects showing up for any local accounts I've created. You are right. I think the private group of a user is/should be deleted at the same time when you delete a user. Is it normal that private groups do not show up in the user group listing or with ipa group-find commands? I thought I remembered seeing them on a freeipa 3 installation but I've checked a couple 4 installs and they don't show up. I just had a random issue a little bit ago with another account when I checked the user groups in the web interface it popped with an unknown error dialog. I have not been able to reproduce it again and don't see anything in the error logs or access log which would indicate any problems. All that being said, I put 389-ds-base-1.3.3.1-16.el7_1.x86_64 on the box yesterday and the error has not shown since. So I'm not sure if it was because of the minor upgrade or cycling the daemon. The logs gave a lot of information but without a test case it could be difficult to identify the RC. Now as I mentioned I hit (with a non systematic test case) an other bug when deleting a user. It was impossible to remove the entry/group. In this bug I tested on standalone instance but on replicated topology I wonder if it could have the same symptom. I've not been able to reproduce the issue in my sandbox environment so I'm not sure. It is also replicated. -andy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] RHEL5 clients not getting ssh key
On 04/30/2015 02:56 PM, Aric Wilisch wrote: Is there a trick to getting a users SSH key that’s attached to their FreeIPA account to work on RHEL 5 servers? users can ssh into the RHEL 6 clients with no issues but they still get prompted for their passwords on the RHEL 5 server, so it’s not pushing down their ssh keys. Thanks! Regards, -- Aric Wilisch awili...@gmail.com Well, RHEL-5's latest build should be sssd-1.5.1-71.el5, but the SSH public key support was added in SSSD 1.8: https://fedorahosted.org/sssd/ticket/610 So I do not know any way besides upgrading to RHEL-6/RHEL-7 or backporting the SSSD 1.8+ yourself (which I do not expect to be an easy task). Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] RHEL5 clients not getting ssh key
On Thu, Apr 30, 2015 at 03:13:44PM +0200, Martin Kosek wrote: On 04/30/2015 02:56 PM, Aric Wilisch wrote: Is there a trick to getting a users SSH key that’s attached to their FreeIPA account to work on RHEL 5 servers? users can ssh into the RHEL 6 clients with no issues but they still get prompted for their passwords on the RHEL 5 server, so it’s not pushing down their ssh keys. Thanks! Regards, -- Aric Wilisch awili...@gmail.com Well, RHEL-5's latest build should be sssd-1.5.1-71.el5, but the SSH public key support was added in SSSD 1.8: https://fedorahosted.org/sssd/ticket/610 So I do not know any way besides upgrading to RHEL-6/RHEL-7 or backporting the SSSD 1.8+ yourself (which I do not expect to be an easy task). The 1.9 branch should build and work on RHEL-5. The newer branches might not (iow, upstream dropped RHEL-5 support). -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] RHEL5 clients not getting ssh key
On (30/04/15 15:34), Jakub Hrozek wrote: On Thu, Apr 30, 2015 at 03:13:44PM +0200, Martin Kosek wrote: On 04/30/2015 02:56 PM, Aric Wilisch wrote: Is there a trick to getting a users SSH key that’s attached to their FreeIPA account to work on RHEL 5 servers? users can ssh into the RHEL 6 clients with no issues but they still get prompted for their passwords on the RHEL 5 server, so it’s not pushing down their ssh keys. Thanks! Regards, -- Aric Wilisch awili...@gmail.com Well, RHEL-5's latest build should be sssd-1.5.1-71.el5, but the SSH public key support was added in SSSD 1.8: https://fedorahosted.org/sssd/ticket/610 So I do not know any way besides upgrading to RHEL-6/RHEL-7 or backporting the SSSD 1.8+ yourself (which I do not expect to be an easy task). The 1.9 branch should build and work on RHEL-5. But IIRC openssh-server should be patched as well. LS -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] [WARNING] Trusts are broken in Fedora 22
Hi, If you are eager to try Fedora 22 beta and overall try FreeIPA in Fedora 22, be aware that trusts to Active Directory are currently broken due to Samba 4.2.1 update in Fedora 22. I've pushed build [1] of Samba today that at least allows Samba processes to start properly but establishing trust will fail due to changes in Samba client libraries. I'm investigating the reason for the issues and hope to get them fixed before Fedora 22 final freeze comes. [1] https://admin.fedoraproject.org/updates/samba-4.2.1-7.fc22 -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] RHEL5 clients not getting ssh key
On Thu, Apr 30, 2015 at 04:32:30PM +0200, Lukas Slebodnik wrote: On (30/04/15 15:34), Jakub Hrozek wrote: On Thu, Apr 30, 2015 at 03:13:44PM +0200, Martin Kosek wrote: On 04/30/2015 02:56 PM, Aric Wilisch wrote: Is there a trick to getting a users SSH key that’s attached to their FreeIPA account to work on RHEL 5 servers? users can ssh into the RHEL 6 clients with no issues but they still get prompted for their passwords on the RHEL 5 server, so it’s not pushing down their ssh keys. Thanks! Regards, -- Aric Wilisch awili...@gmail.com Well, RHEL-5's latest build should be sssd-1.5.1-71.el5, but the SSH public key support was added in SSSD 1.8: https://fedorahosted.org/sssd/ticket/610 So I do not know any way besides upgrading to RHEL-6/RHEL-7 or backporting the SSSD 1.8+ yourself (which I do not expect to be an easy task). The 1.9 branch should build and work on RHEL-5. But IIRC openssh-server should be patched as well. Perhaps, you definitely need the AuthorizedKeysCommand and similar. Honza might know best.. At any rate, upgrading from RHEL-5 to something recent is a good idea :-) -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] RHEL5 clients not getting ssh key
I wish I could, but unfortunately these are RHEL 5 because the client has not yet upgraded their software to work on 6 or 7, so I’m stuck with a RHEL 5 infrastructure for awhile. As long as it authenticates and sudo works we may just have to live with the keys not working. Thanks for the info though. I might try 1.9 and see if that fixes the problem. Regards, -- Aric Wilisch awili...@gmail.com On Apr 30, 2015, at 10:42 AM, Jakub Hrozek jhro...@redhat.com wrote: On Thu, Apr 30, 2015 at 04:32:30PM +0200, Lukas Slebodnik wrote: On (30/04/15 15:34), Jakub Hrozek wrote: On Thu, Apr 30, 2015 at 03:13:44PM +0200, Martin Kosek wrote: On 04/30/2015 02:56 PM, Aric Wilisch wrote: Is there a trick to getting a users SSH key that’s attached to their FreeIPA account to work on RHEL 5 servers? users can ssh into the RHEL 6 clients with no issues but they still get prompted for their passwords on the RHEL 5 server, so it’s not pushing down their ssh keys. Thanks! Regards, -- Aric Wilisch awili...@gmail.com Well, RHEL-5's latest build should be sssd-1.5.1-71.el5, but the SSH public key support was added in SSSD 1.8: https://fedorahosted.org/sssd/ticket/610 So I do not know any way besides upgrading to RHEL-6/RHEL-7 or backporting the SSSD 1.8+ yourself (which I do not expect to be an easy task). The 1.9 branch should build and work on RHEL-5. But IIRC openssh-server should be patched as well. Perhaps, you definitely need the AuthorizedKeysCommand and similar. Honza might know best.. At any rate, upgrading from RHEL-5 to something recent is a good idea :-) -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org http://freeipa.org/ for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Common Name for the ipa-cacert-manage command
William Graboyes wrote: Hi list, The end goal is to eliminate self signed certs from user interaction with FreeIPA, without having to roll out changes to each user in the house (and remote locations). So basically changing the CA to a trusted CA that will not bring scare the users with Site security cannot be verified, return to safety. The problem with the CN is that when it is read from the CSR the CN=Certificate Authority. Which is not an acceptable CN according to the tool we use for generating certs, The tool we use expects a CN of something along the lines of example.com. That sounds odd. The CN of a CA doesn't represent a machine or a specific domain, it represents itself. Granted Certificate Authority isn't all that unique a name either, but it's what we defaulted to, IIRC based on the dogtag defaults. Changing it might have other odd side-effects too as it's hardcoded in a few other places. I'm not exactly sure what would break, if anything. It sounds like your tool is issuing a server cert, not a CA cert. A server cert traditionally has used cn=FQDN,rest of subject. That doesn't really apply to a CA. So it's changeable if you hack some installer code, but there be dragons. rob Thanks, Bill On 4/21/15 2:55 PM, Rob Crittenden wrote: William Graboyes wrote: Hi List, I am having yet another issue, when I run the following command: ipa-cacert-manage renew --external-ca It does output the CSR, however the CN is not a valid name (Certificate Authority). Is it possible to change the output of this command to use an external CA that requires a proper common name to be in the CSR? What I am trying to do is change from the internal self signed certs to an external CA signing system. What isn't valid about the name? This would make the IPA CA a subordinate of the external CA. Is that what you want? rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Common Name for the ipa-cacert-manage command
Let me ask this a different way. What is the easiest method of using a trusted third party cert for the web UI? Running IPA 4.1.0 on Centos 7. Thanks, Bill On 4/30/15 1:44 PM, Rob Crittenden wrote: William Graboyes wrote: Hi list, The end goal is to eliminate self signed certs from user interaction with FreeIPA, without having to roll out changes to each user in the house (and remote locations). So basically changing the CA to a trusted CA that will not bring scare the users with Site security cannot be verified, return to safety. The problem with the CN is that when it is read from the CSR the CN=Certificate Authority. Which is not an acceptable CN according to the tool we use for generating certs, The tool we use expects a CN of something along the lines of example.com. That sounds odd. The CN of a CA doesn't represent a machine or a specific domain, it represents itself. Granted Certificate Authority isn't all that unique a name either, but it's what we defaulted to, IIRC based on the dogtag defaults. Changing it might have other odd side-effects too as it's hardcoded in a few other places. I'm not exactly sure what would break, if anything. It sounds like your tool is issuing a server cert, not a CA cert. A server cert traditionally has used cn=FQDN,rest of subject. That doesn't really apply to a CA. So it's changeable if you hack some installer code, but there be dragons. rob Thanks, Bill On 4/21/15 2:55 PM, Rob Crittenden wrote: William Graboyes wrote: Hi List, I am having yet another issue, when I run the following command: ipa-cacert-manage renew --external-ca It does output the CSR, however the CN is not a valid name (Certificate Authority). Is it possible to change the output of this command to use an external CA that requires a proper common name to be in the CSR? What I am trying to do is change from the internal self signed certs to an external CA signing system. What isn't valid about the name? This would make the IPA CA a subordinate of the external CA. Is that what you want? rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Common Name for the ipa-cacert-manage command
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi list, The end goal is to eliminate self signed certs from user interaction with FreeIPA, without having to roll out changes to each user in the house (and remote locations). So basically changing the CA to a trusted CA that will not bring scare the users with Site security cannot be verified, return to safety. The problem with the CN is that when it is read from the CSR the CN=Certificate Authority. Which is not an acceptable CN according to the tool we use for generating certs, The tool we use expects a CN of something along the lines of example.com. Thanks, Bill On 4/21/15 2:55 PM, Rob Crittenden wrote: William Graboyes wrote: Hi List, I am having yet another issue, when I run the following command: ipa-cacert-manage renew --external-ca It does output the CSR, however the CN is not a valid name (Certificate Authority). Is it possible to change the output of this command to use an external CA that requires a proper common name to be in the CSR? What I am trying to do is change from the internal self signed certs to an external CA signing system. What isn't valid about the name? This would make the IPA CA a subordinate of the external CA. Is that what you want? rob -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVQofVAAoJEJFMz73A1+zrIysP+QFRo04UdfWhJxfWSkkG+0Ig 1kMqQuTN3/ee4AQ/g6rqMUhCPbWTh5MeM2vMf346hrEyq1m/1EpCflj3OfF0Rk6u S5k4rJBatglaGBWwjp1bufgLBrFveLNrVVDBE4tAb4+Ss8sQbT+2rgdVKuyNiVU0 msPGpNDh9XaL5neXbzUyo2sJ1tVV0ltwI6St58dF1EhqwVSTm62+tkpixoMez2FX JEuSvOQMk0k29Sox3kNW4SQB+/lkv3IveEe/gow0PoRQNom9jsR04tjFJn7rB8mo T0BrKB0jVbvjqwzhB8OHzijmnQZG4Jg2y10uxju+6wKTWibMZh9XT67K53zwE4Cg jNRuRf1Ukei/R8e4HggICKLlFdSjb/aBSQESNhwdCosUlT6XGrZVNjNz3TRQaAtM E4eYny9kdcAfOBaafMjViPJPxJf+98X9x3VbIxdKmSOZzi9rSelZetuK7w9hpn7q rJxHyy363PhzwDfEmBfbnXE2nmVWVYONwb8KI0E66fCs2ilH9ElqwG/eBpFDxI5M e10d50QrCHn2UkNbHAV6sQVgIYeGoJT34dAT6jRqUvF02tH1bcIWakqZrjgyw0wh 4VBpKnh3jmDC+sKv++7AeAccxqY73Y83lhy00xuXckiLDoS3d1CLlpQtpWl9cFrp URRCyh9IDBo6sgMrm2Sn =vz3J -END PGP SIGNATURE- -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Common Name for the ipa-cacert-manage command
On 04/30/2015 04:50 PM, William Graboyes wrote: Let me ask this a different way. What is the easiest method of using a trusted third party cert for the web UI? Make IPA CA-less with just certs from that 3rd party CA installed or make IPA trust that CA and be a sub CA. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#install-ca-options Running IPA 4.1.0 on Centos 7. Thanks, Bill On 4/30/15 1:44 PM, Rob Crittenden wrote: William Graboyes wrote: Hi list, The end goal is to eliminate self signed certs from user interaction with FreeIPA, without having to roll out changes to each user in the house (and remote locations). So basically changing the CA to a trusted CA that will not bring scare the users with Site security cannot be verified, return to safety. The problem with the CN is that when it is read from the CSR the CN=Certificate Authority. Which is not an acceptable CN according to the tool we use for generating certs, The tool we use expects a CN of something along the lines of example.com. That sounds odd. The CN of a CA doesn't represent a machine or a specific domain, it represents itself. Granted Certificate Authority isn't all that unique a name either, but it's what we defaulted to, IIRC based on the dogtag defaults. Changing it might have other odd side-effects too as it's hardcoded in a few other places. I'm not exactly sure what would break, if anything. It sounds like your tool is issuing a server cert, not a CA cert. A server cert traditionally has used cn=FQDN,rest of subject. That doesn't really apply to a CA. So it's changeable if you hack some installer code, but there be dragons. rob Thanks, Bill On 4/21/15 2:55 PM, Rob Crittenden wrote: William Graboyes wrote: Hi List, I am having yet another issue, when I run the following command: ipa-cacert-manage renew --external-ca It does output the CSR, however the CN is not a valid name (Certificate Authority). Is it possible to change the output of this command to use an external CA that requires a proper common name to be in the CSR? What I am trying to do is change from the internal self signed certs to an external CA signing system. What isn't valid about the name? This would make the IPA CA a subordinate of the external CA. Is that what you want? rob -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Common Name for the ipa-cacert-manage command
With respect, neither option is realistic in the common case. Unless I'm mistaken, a CA-less installation will break in ~1 year when host certificates expire and are not automatically renewed via certmonger. Option 2 (sub-CA) is, as far as I can tell, also not feasible since no public CA will sell subordinate CA certificates commercially. At least not that I can find. In our case, the only option is to resign ourselves to using self-signed certificates for the UI. End users can import IPA CA root cert if they choose. On Thu, Apr 30, 2015 at 2:45 PM, Dmitri Pal d...@redhat.com wrote: On 04/30/2015 04:50 PM, William Graboyes wrote: Let me ask this a different way. What is the easiest method of using a trusted third party cert for the web UI? Make IPA CA-less with just certs from that 3rd party CA installed or make IPA trust that CA and be a sub CA. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#install-ca-options Running IPA 4.1.0 on Centos 7. Thanks, Bill On 4/30/15 1:44 PM, Rob Crittenden wrote: William Graboyes wrote: Hi list, The end goal is to eliminate self signed certs from user interaction with FreeIPA, without having to roll out changes to each user in the house (and remote locations). So basically changing the CA to a trusted CA that will not bring scare the users with Site security cannot be verified, return to safety. The problem with the CN is that when it is read from the CSR the CN=Certificate Authority. Which is not an acceptable CN according to the tool we use for generating certs, The tool we use expects a CN of something along the lines of example.com. That sounds odd. The CN of a CA doesn't represent a machine or a specific domain, it represents itself. Granted Certificate Authority isn't all that unique a name either, but it's what we defaulted to, IIRC based on the dogtag defaults. Changing it might have other odd side-effects too as it's hardcoded in a few other places. I'm not exactly sure what would break, if anything. It sounds like your tool is issuing a server cert, not a CA cert. A server cert traditionally has used cn=FQDN,rest of subject. That doesn't really apply to a CA. So it's changeable if you hack some installer code, but there be dragons. rob Thanks, Bill On 4/21/15 2:55 PM, Rob Crittenden wrote: William Graboyes wrote: Hi List, I am having yet another issue, when I run the following command: ipa-cacert-manage renew --external-ca It does output the CSR, however the CN is not a valid name (Certificate Authority). Is it possible to change the output of this command to use an external CA that requires a proper common name to be in the CSR? What I am trying to do is change from the internal self signed certs to an external CA signing system. What isn't valid about the name? This would make the IPA CA a subordinate of the external CA. Is that what you want? rob -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Benjamen Keroack *Infrastructure/DevOps Engineer* benja...@dollarshaveclub.com -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Common Name for the ipa-cacert-manage command
I have to agree with Benjamen here. I guess it is time to get deep into API documentation. This is a hell of a lot of hoops to jump through just so that users who don't have shell access can easily change their passwords without having to see a scare page. Distributing the IPA CA is not an option at this point, as we have a very odd desktop support model. I thought all of this was to be fixed in 4.1, which is why I went 4.1... and now nothing has changed... and I am back to square 1. This is the only, and I am serious here, the only gating factor for FreeIPA going into production. The self-signed certs on the UI. It really isn't safe or secure to tell users to Just trust the self signed cert. You create an easy vector for users to get sucked into a phishing trap. Next question, Has anyone made or documented an external password change program for freeipa? On 4/30/15 3:28 PM, Benjamen Keroack wrote: With respect, neither option is realistic in the common case. Unless I'm mistaken, a CA-less installation will break in ~1 year when host certificates expire and are not automatically renewed via certmonger. Option 2 (sub-CA) is, as far as I can tell, also not feasible since no public CA will sell subordinate CA certificates commercially. At least not that I can find. In our case, the only option is to resign ourselves to using self-signed certificates for the UI. End users can import IPA CA root cert if they choose. On Thu, Apr 30, 2015 at 2:45 PM, Dmitri Pal d...@redhat.com wrote: On 04/30/2015 04:50 PM, William Graboyes wrote: Let me ask this a different way. What is the easiest method of using a trusted third party cert for the web UI? Make IPA CA-less with just certs from that 3rd party CA installed or make IPA trust that CA and be a sub CA. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#install-ca-options Running IPA 4.1.0 on Centos 7. Thanks, Bill On 4/30/15 1:44 PM, Rob Crittenden wrote: William Graboyes wrote: Hi list, The end goal is to eliminate self signed certs from user interaction with FreeIPA, without having to roll out changes to each user in the house (and remote locations). So basically changing the CA to a trusted CA that will not bring scare the users with Site security cannot be verified, return to safety. The problem with the CN is that when it is read from the CSR the CN=Certificate Authority. Which is not an acceptable CN according to the tool we use for generating certs, The tool we use expects a CN of something along the lines of example.com. That sounds odd. The CN of a CA doesn't represent a machine or a specific domain, it represents itself. Granted Certificate Authority isn't all that unique a name either, but it's what we defaulted to, IIRC based on the dogtag defaults. Changing it might have other odd side-effects too as it's hardcoded in a few other places. I'm not exactly sure what would break, if anything. It sounds like your tool is issuing a server cert, not a CA cert. A server cert traditionally has used cn=FQDN,rest of subject. That doesn't really apply to a CA. So it's changeable if you hack some installer code, but there be dragons. rob Thanks, Bill On 4/21/15 2:55 PM, Rob Crittenden wrote: William Graboyes wrote: Hi List, I am having yet another issue, when I run the following command: ipa-cacert-manage renew --external-ca It does output the CSR, however the CN is not a valid name (Certificate Authority). Is it possible to change the output of this command to use an external CA that requires a proper common name to be in the CSR? What I am trying to do is change from the internal self signed certs to an external CA signing system. What isn't valid about the name? This would make the IPA CA a subordinate of the external CA. Is that what you want? rob -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
