Re: [Freeipa-users] Providing minimal permissions to read replication status
On 1 August 2013 09:36, Martin Kosek mko...@redhat.com wrote: The patch for this would do basically this: - remove the following aci: (targetattr != aci)(version 3.0; aci replica admins read access; allow (read, search, compare) groupdn = ldap:///cn=Modify Replication Agreements,cn=permissions,cn=pbac,$SUFFIX;) ... from installer and from LDAP as it is too general - add new permission ACI like this: (targetattr=*)(targetfilter=(|(objectclass=nsds5Replica)(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectClass=nsMappingTree)))(version 3.0; acl permission:Read Replication Agreements; allow (read, search, compare) groupdn = ldap:///cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX;) - make sure that Replication Administrators privilege has it assigned. I created an upstream ticket to track this effort: https://fedorahosted.org/freeipa/ticket/3829 Reading the upstream documentation I'm wondering if it'd be sensible to include an additional ACI in replica-acis.ldif of: dn: $SUFFIX changetype: modify add: aci aci: (targetattr=dn nsDS5ReplConflict nsUniqureID)(targetfilter=(|(objectclass=nsTombstone)(nsDS5ReplConflict=*)))((version 3.0; aci conflict read access; allow (read, search, compare) groupdn = ldap:///cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX;) From the upstream documentation here: https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html-single/Configuration_Command_and_File_Reference/index.html#Replication_Attributes_under_cnreplica_cnsuffixName_cnmapping_tree_cnconfig This would allow a user with Read Replication Agreements permission to be able to search for conflicts or tombstone records which would seem sane from a monitoring point of view... What do you think? Also just to confirm the only thing I need to do with ACIs like this is to update the ldif (delegation.ldif and replica-acis.ldif) with the new role/privilege/permission and acis in install/share for the new installs and add an appropriate entry (not quite ldif) in install/updates to update the default schema of those updating in future, given no new attributes - right? Cheers, James ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Providing minimal permissions to read replication status
On 1 August 2013 15:55, Rob Crittenden rcrit...@redhat.com wrote: James Hogarth wrote: On 1 August 2013 09:36, Martin Kosek mko...@redhat.com mailto:mko...@redhat.com wrote: The patch for this would do basically this: - remove the following aci: (targetattr != aci)(version 3.0; aci replica admins read access; allow (read, search, compare) groupdn = ldap:///cn=Modify Replication Agreements,cn=permissions,cn=**pbac,$SUFFIX;) ... from installer and from LDAP as it is too general - add new permission ACI like this: (targetattr=*)(targetfilter=(**|(objectclass=nsds5Replica)(** objectclass=**nsds5replicationagreement)(**objectclass=** nsDSWindowsReplicationAgreemen**t)(objectClass=nsMappingTree))** )(version 3.0; acl permission:Read Replication Agreements; allow (read, search, compare) groupdn = ldap:///cn=Read Replication Agreements,cn=permissions,cn=**pbac,$SUFFIX;) - make sure that Replication Administrators privilege has it assigned. I created an upstream ticket to track this effort: https://fedorahosted.org/**freeipa/ticket/3829https://fedorahosted.org/freeipa/ticket/3829 Reading the upstream documentation I'm wondering if it'd be sensible to include an additional ACI in replica-acis.ldif of: dn: $SUFFIX changetype: modify add: aci aci: (targetattr=dn nsDS5ReplConflict nsUniqureID)(targetfilter=(|(**objectclass=nsTombstone)(** nsDS5ReplConflict=*)))((**version 3.0; aci conflict read access; allow (read, search, compare) groupdn = ldap:///cn=Read Replication Agreements,cn=permissions,cn=** pbac,$SUFFIX;) From the upstream documentation here: https://access.redhat.com/**site/documentation/en-US/Red_** Hat_Directory_Server/9.0/html-**single/Configuration_Command_** and_File_Reference/index.html#**Replication_Attributes_under_** cnreplica_cnsuffixName_**cnmapping_tree_cnconfighttps://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html-single/Configuration_Command_and_File_Reference/index.html#Replication_Attributes_under_cnreplica_cnsuffixName_cnmapping_tree_cnconfig This would allow a user with Read Replication Agreements permission to be able to search for conflicts or tombstone records which would seem sane from a monitoring point of view... What do you think? I think this would be a separate issue. Being able to find the conflicting issues leads directly to the question what do I do with them? That is ticket https://fedorahosted.org/**freeipa/ticket/1025https://fedorahosted.org/freeipa/ticket/1025 Thanks Rob - I think it worthwhile adding the permissions in place to at least find them as a 'quick win' as it were ... What to do after that is an interesting question and would probably take a fair chuck of work to make it nicely visible plus show ways to resolve it. Also just to confirm the only thing I need to do with ACIs like this is to update the ldif (delegation.ldif and replica-acis.ldif) with the new role/privilege/permission and acis in install/share for the new installs and add an appropriate entry (not quite ldif) in install/updates to update the default schema of those updating in future, given no new attributes - right? You'll need to create a .update file in install/updates to modify an existing installation. That's great - I had a look through the README in there and looking at other similar bits appears to be fairly simple. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Providing minimal permissions to read replication status
Hi, We're looking to add monitoring to our IPA replicas and want to provide a user with the minimum possible permissions to do so. Allowing the user to have the Replication Administrators role works but for monitoring the ability to add/modify/remove is overkill by a long shot. There's no existing permission for Read Replication Agreements - only add, remove and modify. I've tried to use ipa perimssion-add with --filter to allow access to objectClass=nsds5replicationagreement but checking the status via: ldapsearch -Y GSSAPI -h c6test2.c6ipa.local -b cn=config '(objectclass=nsds5replicationagreement)' Does not show anything unless the account being tested with gets replication administrator privileges... I've tried using subtree as well but the ipa command errors that the base of cn=config is not $SUFFIX ... and out of scope. What am I missing to set this up - or is this not possible with the role/privilege/permission mechanism within IPA? I can see how the replication administration permissions are added in replica-acis.ldif but I'm concerned that if I manually add an ACI via pure LDIF commands it will cause issues with future IPA upgrades due to schema differences - so was hoping to remain within the IPA command side of things... 1) Is this even possible with the ipa command? 2) If I use ldapmodify to add a new permission by hand via ldif for Read Replication Agreements will this likely break on IPA upgrades in future? Cheers, James ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Question about design of ldap dns
Please contact me on IRC (pspacek in #freeipa @ FreeNode) or via e-mail. We need to coordinate, because bind-dyndb-ldap is undergoing heavy refactoring right now. Also, remember that modification in bind-dyndb-ldap will require modification on FreeIPA side (CLI/WebUI/API). Sure - I'm usually in #freeipa as JHogarth when I'm about ... Yes indeed .. I've been doing quite a bit of work in dns.js the past week or so to expose TTL in general anyway... We can't do this, because definition of *Record attributes is outside of our control. Definitions of these attributes come from http://drift.uninett.no/nett/**ip-nett/dnsattributes.schemahttp://drift.uninett.no/nett/ip-nett/dnsattributes.schema and it is used by BIND DLZ LDAP driver. Ah that's a shame ... it would have been quite a smooth way to handle it but compatibility is of course critical. Could you post some real world examples, please? I would love to see some real world records with real TTLs and statistics. How many names with different TTLs have you? How many names and records have you in total? As one example TXT record and SSHFP to describe a system (and it's fingerprint) having a long TTL since they are unlikely to change and an A record with a shorter TTL for a dynamic DNS scenario with a non-sticky lease. There was a specific issue I was bumping into with this in the past (but not a major one) and became an itch to scratch... especially since BIND zone files would support such a setup but the bind-dyndb-ldap won't ... the disparity was something that niggled at me. In all honesty this is an edge case and since I was planning to dive in anyway I thought I might as well take a look given I have some free time at the moment... The default TTL in bind-dyndb-ldap and the exposing/modifying TTL in the Web UI is not dependent on such behaviour in any way. This could work, but it has significant overhead. At least indexes in LDAP server could grow rapidly. That is a legitimate concern for sure... The other problem is that you will lost the uniqueness-check on LDAP side. DNS doesn't allow one record with same name and data to appear multiple times and current attribute-based design prevents this 'for free'. But you would still be limited to this since there could only be one arecord, txtrecord, etc for a given idnsname with that structure. The other problem is that records in single RRset can't have multiple TTL values. I.e. (under single name) all A records have to have the same TTL, all records has to have same TTL etc. Hmm I'll have to check BIND again but I thought that when doing round robin A records (as an example) differing TTL was possible ... but admittedly I've not verified this and this would be an inconsistency if so. Of course, all of these can be handled in bind-dyndb-ldap, but doing so on database side is much more elegant. Agreed on this dn: idnsName=bar+dNSTTL=3600,**idnsName=example.com idnsName: bar dNSTTL: 3600 aRecord: 5.6.7.8 This way you don't have to change the format of existing attributes nor add new attributes. This one is my favourite, but again: It will require refactoring on FreeIPA side. Also, I'm not sure if this could work with BIND DLZ LDAP... I do like the compound RDN idea but it sounds like it would potentially be a lot of upheaval... To summarize it: Is it worth to spend time on this? I would love to see some real numbers. Good question! It's an itch I have a couple of weeks to scratch at the moment so there's no 'cost' on my time right now associated with it (although I recognise it increases complexity for the maintainers and QA of course as an after-effect)... but the complexity is fairly high and could potentially touch a lot of areas... The more basic bit of work I was doing (just the exposure and modification of TTL in the UI) would have a far improved cost-benefit ratio and only touches dns.js and dns.py (the latter I propose exposing TTL by default rather than needing --all for it in the API ... it makes the dns.js changes cleaner). Adding the ability to configure default TTL in bind-dyndb-ldap also doesn't need any of the per RRtype stuff so avoids complexity there... Thank you for your time and passion! Well it's about time the linux world had something like this (rather than the old mish-mash of kerberos, openldap, etc and associated scripts to sort of glue users together that was the previous situation) so I champion it wherever I can! James ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Question about design of ldap dns
Hi guys, I'm just picking up the nice to have ticket of configure the default TTL as part of my general TTL refactor work seeing as the exposing and modification of TTL in the UI is unlikely to be complete before 3.3 freeze (mostly working but a few bugs remaining) : https://fedorahosted.org/bind-dyndb-ldap/ticket/70 https://fedorahosted.org/freeipa/ticket/2956 The approach I'm considering is to make the record capable of an individual TTL by just appending the TTL to the record so it would look like: dn: idnsName=bar, idnsName=example.com, cn=dns, dc=example, dc=com idnsName: bar ARecord: 192.168.1.100 7200 This is an approach that matches how things like MX and SRV are dealt with (except those have numbers at the front) and would require much simpler modifications. Then there would be a precedence to the actual TTL used in this order: 1) If a TTL is in the record data use that 2) If a TTL is in the idnsName data (the current dnsTTL attribute) then use that 3) If a TTL is in the zone data (as per the ticket name to be decided) then use that 4) If a TTL is specified in the named.conf configuration for the bind-dyndb-ldap plugin then use that. Although potentially not as nice as making each data entry a first class citizen as an object in LDAP such as for an example: dn: aRecord=192.168.1.100,idnsName=bar, idnsName=example.com, cn=dns, dc=example, dc=com aRecordName: bar aRecordData: 192.168.1.100 aRecordTTL: 7200 It'd require far less upheaval in terms of migrations and testing... What are your thoughts on this before I start digging into this part of the code base? Cheers, James ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] sudo rules user and host group bugs?
Did anyone find a solution for this? I am having the same experience. Wow that was a mess... To use hostgroups for sudo ensure nisdomainname is set on the hosts to the IPA domain. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] named seg faulting
I meanwhile I recommend you to build version 2.6: https://fedorahosted.org/released/bind-dyndb-ldap/bind-dyndb-ldap-2.6.tar.bz2 It includes some fixes not-yet accepted for RHEL. Interesting... I might build and test but generally I prefer to keep to packages accepted to rhel... As an FYI to other CentOS users the srpm was published yesterday and was built and pushed to the CentOS repositories last night. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] named seg faulting
Upgrade to bind-dyndb-ldap-2.3-2.el6_4.1 should fix the problem. Thanks Petr ... looks like that's not in the CentOS repositories ... I'll give those guys a heads up ... A quick look and it appears that the SRPM isn't in the public FTP server ... opened bug https://bugzilla.redhat.com/show_bug.cgi?id=980046 to get this corrected. James ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo Commands and groups confusion
I believe that at one point we included a configuration very similar to the snippet above in man sssd-sudo. It should be there in 6.4, not 100% sure now. Just checked the man page and indeed that minimal snippet is there ... I really need to spend more time going through new man pages etc at each point release! My quick testing has it working a treat though and it's a lot more lightweight with the caching going on than it was before I've just let a couple of my colleagues know who were struggling a bit with the ldap-sudo and binding stuff ... this is just so much simpler. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Managing Sudo through FreeIPA
Hi, caching capabilities were not optimal in the tech preview, but it was fully functional (or at least should be, I don't think anyone really tried it in production), unless sssd is configured with multiple domains. I looked at the 6.3 technical notes for sudo, sssd and ipa but couldn't see any reference to sudo support in IPA/SSSD natively (as opposed to LDAP integration) ... the Identity Management guide still refers to the old nslcd.conf file and not sudo-ldap.conf neveremind native integration... Do you have any details on how to go about testing this? ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Certificate serial number not found error
Hi, When trying to view a particular service (or the related host) I'm getting the following error in the UI: IPA Error 4301 Certificate operation cannot be completed: EXCEPTION (Certificate serial number 0xffe000c not found) Now I've seen similar issue in the past when replication has played up and then using ipa-csmanage-replica and forcing syncs (or finding the system the certificate is registered on and deleting it there) has cleared it up... Unfortunately I suspect this was on an old replica which no longer exists given the error occurs on either of the pair I now have for this host and service... Given there's no 'ignore warning and remove what you can' so far as I can see I suspect I'm going to have to delve into LDAP to unravel the mess but does anyone know the relevant areas in both 389 servers to do this as safely as possible and reduce the risk in doing so as much as possible? Regards, James ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] IPA Error 401 certificate not found
Hi all, I was adding and removing the same hosts and a fairly high rate from IPA and I've managed to get myself into an odd situation... On trying to delete or unprovision one of the hosts I'm getting IPA error 401: Certificate operation cannot be completed: EXCEPTION (Certificate serial number 0x2fff0009 not found) I suspect I've hit a replication conflict... Has anyone encountered this before or know a way to resolve it cleanly? Regards, James ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA Error 401 certificate not found
I suspect I've hit a replication conflict... Just to close this off ... it was a replication issue - the certificates hadn't yet replicated... deleting from the server originally enrolled against it was fine. James ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Heads up on dynamic DNS TTL weird behaviour...
Hey all, Just a quick heads up in for the mailing list archive in case someone bumps into this after drilling through it a bit in IRC on Friday... If you are making use of --enable-dns-updates in ipa-client-install and for whatever reason your client may change its address more often than once per day after the first update other systems won't pick up the change for 24 hours... The cause is down to the difference in how the DNS record is created/updated on the initial install versus SSSD handling it later... The initial install has a hardcoded TTL of 1200 set at line 957 of /usr/sbin/ipa-client-install (as per Centos 6.3 current)... SSSD has a hardcoded TTL set of 86400 in the provider ipa/ipa_dyndns.c (line 989 or thereabouts)... The consequence is that when the system is first registered the DNS record that gets created only has a TTL of 1200 but if the IP address changes for that host then the record gets updated with a TTL of 86400 so that other DNS servers (or clients) will then have a day until it times out (unless caches can be manually cleared) and the correct address is found for any changes subsequent to that... This is a bit of an edge case given you'd need 2 changes of IP address since the initial registration and have SSSD configured to carry out the DNS updates (rather than a dhcpd/bind integration for example) for this to have an effect on the environment... I have filed a bug and a patch with the SSSD mailing list/trac but changing this locally requires a recompile of SSSD Moving forwards I plan to expose TTL in the IPA UI and provide a configurable value for TTL for both ipa-client-install and the sssd updates ... I'll update the list in a couple of weeks on any progress made... Kind regards, James ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] hostgroups not working for Sudo commands
Yes I'd missed this, echo nisdomainname ods.vuw.ac.nz /etc/rc.d/rc.local Is it not possible to automate this (sudo setup) more in the ipa-client-install ? control whether you want it via a sudo_enable=yes or no somewhere? Ive added it to my kickstart for now so my sudo setup is mostly automated. RHEL 6.3 added NISDOMAIN as a usable entry in /etc/sysconfig/network by the way - it's a bit cleaner than sticking stuff in rc.local ... ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Roadmap
Is there any information on what the roadmap might be now that 2.2 is out the door? The current roadmap still references the 2.1 release around a year ago. Check out the info here: https://fedorahosted.org/freeipa/roadmap So far as I'm aware the bulk of the 3.0 work is for cross realm (initially only Active Directory?) trusts rather than full syncs of users. There's some 3.1 work slated on there with respect to client certificate management too ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Request for comments - Libvirt (KVM) with VNC via IPA with kerberos authentication
Hi all, As mentioned on IRC today I've finished my write up of using libvirt (kvm virtualization) with VNC consoles and kerberos authentication with an IPA backend I'd be interested in any feedback: http://freeipa.org/page/Libvirt_with_VNC_Consoles Kind regards, James ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Do clients have to be in teh same DNS zone / FQDN as the IPA servers / Kerberos Realm?
but Im getting hammered by my management for instant answers...they asked last night and expect an answer this morning.and I'm expected to catch up and deploy several important solutions/projects all hinging on IPA ASAP... 2.2 isnt in RHEL6.3 though? Are you using fedora, centos or rhel? The last bit implies rhel but then you seem to desire an SLA and a response on the upstream users' mailing list Although there are a large number of people here using IPA along with redhat developers might I suggest for a critical thing where you need an answer within 24 hours you are better off following the standard support channels of your RHEL contract? If you don't have a support contract now could be a good time to explain to management that if they require quick answers then they need to pay for them... if they do things on the cheap then they require patience... ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Request for comments - Apache SNI via IPA with kerberos authentication
I'll try and replicate the blog findings in the course of the next couple of days if it works I'll add it to the wiki ... Set up a test this morning using Centos 6: nss-3.13.1-7.el6_2.x86_64 mod_nss-1.0.8-14.el6_2.x86_64 The behaviour was... odd SNI itself must have been working as the contents differed depending on the domain which matched the expectation from the two virtual hosts however there appears to remain certificate selection issues and/or issues with respect to the the behaviour of the NSS options - only the last NSSCertificateDatabase seemed to apply rather than be local to a given VirtualHost (if separating certificate databases) and if in a common database although Apache reported different nicknamed certificates in error_log only the first NSSNickname seemed to be used to obtain the correct certificate... Set up a similar test on Fedora 17: nss-3.13.4-3.fc17.x86_64 mod_nss-1.0.8-17.fc17.x86_64 Same behaviour occurred (not that surprising given the versions) So the short of it is ignore that blog and Rob is right - mod_nss is not ready yet... if you want SNI you need mod_ssl (or mod_gnutls)... if you have FIPS etc requirements or other reasons to use mod_nss then SNI is not at this time possible if you want valid certificates in place... James ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Request for comments - Apache SNI via IPA with kerberos authentication
Only one nss database may be opened at a time. mod_nss should probably error out if multiple are defined to prevent confusion. I'd think a nickname should be unique to a given VirtualServer. If not then it's a bug. That makes sense - and yeah it should probably error out rather than just open the last without notice. Pretty sure the NSSNickname issue is a bug - but at this time not sure where that lies exactly given that mod_nss doesn't claim SNI support currently anyway I'm going to let this lie for now to get on with other bits and will probably pick it up again in a weke or so to dig a little deeper (ie use multiple IPs and compare behaviour versus on a single IP etc)... If I can find anything relevant I'll open appropriate tickets with the appropriate parties then. For now (and in the context of this thread) I'll not mention mod_nss and leave the wiki page as is. James ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Request for comments - Apache SNI via IPA with kerberos authentication
Hi all, As mentioned on IRC today I've finished my write up of using Apache with SNI and kerberos authentication with an IPA backend I'd be interested in any feedback: http://freeipa.org/page/Apache_SNI_With_Kerberos Kind regards, James ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA in a locked down Active Directory environment
Well, at the moment we only set up a two way trust but the windows admins would certainly be able to delete the outgoing trust right after it is created, it should cause trouble for win users that want to access ipa hosts. We may take an RFE about creating only a one way trust, but it won't be there by 3.0 I think. Gotcha - I know here I'll probably end up with a requirement for windows users to access one or more of my linux systems (and web interfaces) with their windows AD credentials but there is no way the Windows team (or IT Security) would want my users in IPA to be able to log into the windows clients etc in the enterprise. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] How to promote 2.2.0 replica(installed with --setup-ca) to primary master?
But in short the only thing to do is change the CRL generator per those instructions. It is otherwise already a full CA. If none or all of them are generating a CRL it isn't the end of the world either way, you could just end up with slightly different CRLs on different masters which can be confusing. Really trying to get to the bottom of this I've just installed FreeIPA 2.2 on Fedora 17 So far as I can see the first system immediately after being built does not have the following lines discussed in the 'promote replica' documentation in CS.cfg: ca.certStatusUpdateInterval ca.listenToCloneModifications Grabbing the info from the internal dogtag system for the first built system shows: PKI Subsystem Type: Root CA (Security Domain) After having installed the second system there is no change in the first system The second system is identical to the first for the given parameters mentioned in the docs Grabbing the info from the internal dogtag system for the second built system shows: PKI Subsystem Type: CA Clone (Security Domain) This appears to completely differ form the docs on a default install - to the extent described parameters in CS.cfg don't even exist. Finally I decided to mimic a complete failure of the first system and and consequences thereof. Installing a third system and using the second for ipa-replica-prepare all seemed to build cleanly After it was installed both systems apparently were clones according to the internal dogtag info - but replication seemed fine and both appeared to be generating CRLs. The replication was as one would expect - system2 had agreements with systems 1 and 3 ... and system 3 only knew of system 1... Built a client to register against these next The client was able to use ipa-client to join this domain... Next httpd was installed on this client Using the normal methods (ipa service-add, ipa-getcert, ipa-getkeytab) the httpd instance was configured fine with an HTTP service keytab and SSL certificate being monitored via certmonger The only think I can get out of these diagnostics is that the whole 'ROOT' thing only on the first doesn't appear to matter since certificates could still be generated and all instances appeared to be generating CRLs. Sorry for the wordiness but wanted to get all my steps and checks down for reference purposes Hope this helps out the next person who wonders about the whole 'promote' thing in the IPA documentation - it doesn't actually seem to apply in the slightest for a full Dogtag multimaster integrated setup Regards, James ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] PKI Subsystem Type: CA Clone convert to Root
I'll see if I can get one of the dogtag guys to take a look at this. In general, this is not really a big problem. All we are doing here is deciding which of the CAs will generate the CRL. You want just one because other operations are happening at the same time, potentially on other CAs, and if they are all generating a CRL at more or less the same time then resulting CRLs could be different by a cert or two. For consistency sake it is better to do this one one machine and publish it. Other than that there is no master promotion required. All of the servers, particularly those with a CA installed, are equals. Just joined the list following looking in the archives - so apologies for the random quote from a post yesterday This has left me quite confused compared to my infrastructure and directly impacts me as I need to take the first IPA install offline indefinitely On the first system a service pki-cad status shows: PKI Instance Name: pki-ca PKI Subsystem Type: Root CA (Security Domain) On the three systems built subsequently (with dns and CA replica install options) the following is shown: PKI Instance Name: pki-ca PKI Subsystem Type: CA Clone (Security Domain) The section 18.8.1 of the Identity Guide on the docs.redhat.com site refers to entries such as: ca.listenToCloneModifications=true master.ca.agent.host=hostname master.ca.agent.port=port number However on none of my four IPA instances do these lines appear in CS.cfg So far as I can see from ipa-csmanage-replica list the initial system has a replica agreement with each of the other three but no agreements exist between those other three themselves (ie all replication has to go through the initial system). This is a fully updated CentOS 6 system... IPA/PKI packages in the rpmdb: ipa-server-selinux-2.1.3-9.el6.x86_64 libipa_hbac-1.5.1-66.el6_2.3.x86_64 libipa_hbac-python-1.5.1-66.el6_2.3.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-admintools-2.1.3-9.el6.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-python-2.1.3-9.el6.x86_64 ipa-client-2.1.3-9.el6.x86_64 ipa-server-2.1.3-9.el6.x86_64 pki-java-tools-9.0.3-21.el6_2.noarch pki-common-9.0.3-21.el6_2.noarch pki-symkey-9.0.3-21.el6_2.x86_64 pki-util-9.0.3-21.el6_2.noarch pki-ca-9.0.3-21.el6_2.noarch pki-setup-9.0.3-21.el6_2.noarch pki-silent-9.0.3-21.el6_2.noarch pki-native-tools-9.0.3-21.el6_2.x86_64 pki-selinux-9.0.3-21.el6_2.noarch krb5-pkinit-openssl-1.9-22.el6_2.1.x86_64 I can't quite reconcile all the above with the discussions on the mailing list of how no promoting is needed in a dogtag (as opposed to self signed) IPA replication topology So far as I can see at a minimum when the first server gets switched off the other three will no longer exchange certificate information and there might be CRL issues too? Is there any tested procedure to go from a 'Clone' to a 'Root' instance for the CAs (and sort out the replication agreements in the process) in IPA 2.1/2.2? Kind regards, James Hogarth ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
