Re: [Freeipa-users] [SSSD] New mailing list: sssd-users
Hi All, Thanks for the new list. I hope the user list will still get to see some of the design decisions. It would be nice to have input as a user to what is going to be added feature wise to sssd. Cheers, Greg -Original Message- From: sssd-devel-boun...@lists.fedorahosted.org [mailto:sssd-devel- boun...@lists.fedorahosted.org] On Behalf Of Stephen Gallagher Sent: Wednesday, 23 May 2012 3:41 AM To: Development of the System Security Services Daemon; freeipa- us...@redhat.com; freeipa-inter...@redhat.com Subject: [SSSD] New mailing list: sssd-users For quite some time, we have used the sssd-devel mailing list for development and user configuration issue discussions. As the project has grown, it becomes more and more clear that we need to separate these topics into their own lists. So as of today, we now have a new mailing list for user questions. You can subscribe at https://fedorahosted.org/mailman/listinfo/sssd-users This list will be considerably less noisy for our users as they will not be bombarded with patch review emails and other development-centric issues. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] [SSSD] New mailing list: sssd-users
+1 On 05/22/2012 11:47 PM, greg.lehm...@csiro.au wrote: Hi All, Thanks for the new list. I hope the user list will still get to see some of the design decisions. It would be nice to have input as a user to what is going to be added feature wise to sssd. Cheers, Greg -Original Message- From: sssd-devel-boun...@lists.fedorahosted.org [mailto:sssd-devel- boun...@lists.fedorahosted.org] On Behalf Of Stephen Gallagher Sent: Wednesday, 23 May 2012 3:41 AM To: Development of the System Security Services Daemon; freeipa- us...@redhat.com; freeipa-inter...@redhat.com Subject: [SSSD] New mailing list: sssd-users For quite some time, we have used the sssd-devel mailing list for development and user configuration issue discussions. As the project has grown, it becomes more and more clear that we need to separate these topics into their own lists. So as of today, we now have a new mailing list for user questions. You can subscribe at https://fedorahosted.org/mailman/listinfo/sssd-users This list will be considerably less noisy for our users as they will not be bombarded with patch review emails and other development-centric issues. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communicati...@s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18___ 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
Re: [Freeipa-users] PKI Subsystem Type: CA Clone convert to Root
On 05/23/2012 08:59 AM, James Hogarth wrote: 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 They are identical CAs so calling one of them 'Root' and others 'Clone' is quite misleading. One of Dogtag CAs is selected to produce CRLs to have consistent source of revocation information. CRL generation is one of many Dogtag CA options and enabling or disabling this option does not make selected CA 'Root' or 'Clone'. Here is an information on Dogtag CA configuration which should help to clear confusion. General information about related Dogtag CA default configuration: * CRL generation is by default enabled. *ca.crl.issuingPointId.enableCRLUpdates=true *Absence of the above line is a equivalent to **CRL generation being enabled. * CRL cache is by default enabled. *ca.crl.issuingPointId.enableCRLCache=true *Absence of the above line is a equivalent to **CRL cache being enabled. * CA's database maintenance thread is controlled by setting its interval. Its default value is 10 minutes set by the following line: *ca.certStatusUpdateInterval=600* Absence of the above line is a equivalent to setting database maintenance thread interval to 10 minutes. CA's database maintenance thread can be disabled by setting its interval to zero: ca.certStatusUpdateInterval=0 * Monitoring of database replications for the purpose of updating CRL cache is by default disabled. *ca.listenToCloneModifications=false *Absence of the above line is a equivalent to **disabled monitoring of database replications. * Redirection of CRL generation requests is by default disabled. *master.ca.agent.host=/|hostName|/ **master.ca.agent.port=/|portNumber|/ ***Absence of the above lines is a equivalent to**redirection of CRL generation requests being disabled. 1.
[Freeipa-users] I've done it by myself and it works -- Re: Feature request: Web UI for IPA users to reset their own expired passwords
I've coded it with python-kerberos and it works. Pretty rough though. --Gelen. From: Gelen James hahaha_...@yahoo.com To: freeipa-de...@redhat.com freeipa-de...@redhat.com Sent: Sunday, May 20, 2012 2:22 AM Subject: Feature request: Web UI for IPA users to reset their own expired passwords The currently assumption is that all IPA users can login into Unix/Linux machines to change their IPA password, or reset their expired password. But this is not available all the time, so a more general alternative -- web UI -- will be more appreciated. The basic requirements are: 1, The web UI accept user's passwords, expired is also accepted. 2, the authentication is based on IPA Kerberos. 3, authenticated regular IPA user can only reset his/her password only. 4, (bonus) authenticated admin users can alter other users' password as well. Thanks. --Gelen___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] [Freeipa-devel] I've done it by myself and it works -- Re: Feature request: Web UI for IPA users to reset their own expired passwords
Gelen James wrote: I've coded it with python-kerberos and it works. Pretty rough though. Is this something you'd be interested in contributing? rob --Gelen. *From:* Gelen James hahaha_...@yahoo.com *To:* freeipa-de...@redhat.com freeipa-de...@redhat.com *Sent:* Sunday, May 20, 2012 2:22 AM *Subject:* Feature request: Web UI for IPA users to reset their own expired passwords The currently assumption is that all IPA users can login into Unix/Linux machines to change their IPA password, or reset their expired password. But this is not available all the time, so a more general alternative -- web UI -- will be more appreciated. The basic requirements are: 1, The web UI accept user's passwords, expired is also accepted. 2, the authentication is based on IPA Kerberos. 3, authenticated regular IPA user can only reset his/her password only. 4, (bonus) authenticated admin users can alter other users' password as well. Thanks. --Gelen ___ Freeipa-devel mailing list freeipa-de...@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] [Freeipa-devel] I've done it by myself and it works -- Re: Feature request: Web UI for IPA users to reset their own expired passwords
No problem. The code is attached. It is just one python script, with configuration items on the top. Please be reminded that this code is pretty rough and not well-tested as I can not find appropriate documents on how to use python kerberos module. Disclaim: This piece of code just works as a prototype, it is not well-tested, nor DOS attack prove at all, so it could potentially harm or totally destroy someone's authentication system. :( Thanks. --Gelen From: Rob Crittenden rcrit...@redhat.com To: Gelen James hahaha_...@yahoo.com Cc: freeipa-de...@redhat.com freeipa-de...@redhat.com; freeipa-users@redhat.com freeipa-users@redhat.com Sent: Wednesday, May 23, 2012 12:14 PM Subject: Re: [Freeipa-devel] I've done it by myself and it works -- Re: Feature request: Web UI for IPA users to reset their own expired passwords Gelen James wrote: I've coded it with python-kerberos and it works. Pretty rough though. Is this something you'd be interested in contributing? rob --Gelen. *From:* Gelen James hahaha_...@yahoo.com *To:* freeipa-de...@redhat.com freeipa-de...@redhat.com *Sent:* Sunday, May 20, 2012 2:22 AM *Subject:* Feature request: Web UI for IPA users to reset their own expired passwords The currently assumption is that all IPA users can login into Unix/Linux machines to change their IPA password, or reset their expired password. But this is not available all the time, so a more general alternative -- web UI -- will be more appreciated. The basic requirements are: 1, The web UI accept user's passwords, expired is also accepted. 2, the authentication is based on IPA Kerberos. 3, authenticated regular IPA user can only reset his/her password only. 4, (bonus) authenticated admin users can alter other users' password as well. Thanks. --Gelen ___ Freeipa-devel mailing list freeipa-de...@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel kchange.py Description: Binary data ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] ipa ports
We have quite strict firewalls, so I need to specify the IPA network ports accurately. So, we have now opening for: 80/tcp, 88/tcp, 389/tcp, 443/tcp, 464/tcp, 636/tcp 88/udp, 464/udp in to our first IPA server. Now I'm in the process of configuring the first replica. Is there any other ports that needs to be opened between ipa master and replica? We don't serve NTP or DNS from IPA, so I guess these shouldn't be relevant, but I think we want dogtag replicated, so there's maybe some ports for that that needs opening ? Or, to put it another way, which of these ports: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Preparing_for_an_IPA_Installation.html#prereq-ports needs to be opened between ipa server, which for all clients, which for replica and which for administrative clients ? HTTP/HTTPS -- open for all LDAP/LDAPS -- open for all Kerberos-- open for all OCSP responder -- open for all if we use certs dogtag 9443 (agents)-- ? dogtag 9444 (users, SSL)-- ? dogtag 9445 (administrators)-- ? dogtag 9446 (users, client authentication) -- ? dogtag 9701 (Tomcat)-- ? dogtag 7389 (internal LDAP database) -- ? -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] freeipa 2.1.3-9 install with external CA failed
This is a fresh OS and IPA install. I did not create testnick, it was from the install. # certutil -V -u C -n ipa-ca-agent -d /tmp/tmp-aZzm2V certutil: certificate is invalid: Issuer certificate is invalid. # certutil -L -n ipa-ca-agent -d /tmp/tmp-aZzm2V Certificate: Data: Version: 3 (0x2) Serial Number: 5 (0x5) Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: CN=Certificate Authority,O=EXAMPLE.COM Validity: Not Before: Mon May 21 16:54:20 2012 Not After : Sun May 11 16:54:20 2014 Subject: CN=ipa-ca-agent,O=EXAMPLE.COM Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: bb:83:f1:d1:b0:86:64:33:03:b5:52:b5:25:c1:c4:ef: 19:f4:ce:5f:5b:42:36:e4:3f:df:d8:72:5a:1f:e8:a1: 6d:45:8a:f1:b3:4a:93:f4:cd:e9:05:6a:29:b8:b2:93: 49:df:b2:73:74:3d:a8:1c:42:ec:0c:79:9f:9e:85:16: 92:f4:ef:5d:e0:c3:a8:a3:71:bb:20:17:e2:a4:3c:eb: ad:7b:a8:42:b4:65:62:b9:01:07:30:8a:68:f8:f9:9f: f9:73:1b:79:b0:a2:78:44:b6:29:70:d8:65:5d:5f:78: 40:a1:14:01:e5:9b:b0:f0:6e:89:c9:f2:7c:f1:0d:2b: 58:fd:5c:03:2a:b7:a0:79:db:6a:d2:0c:6c:5e:88:c9: 4b:f0:ba:e2:83:d3:bc:a2:39:68:cb:94:8f:0a:0a:e1: 2b:2c:c7:bd:89:41:67:df:6b:d2:4b:64:a4:fe:0a:a6: 74:8a:ef:50:5a:fa:b3:07:8c:e9:46:c0:f4:31:2e:69: 3a:22:78:8d:c6:71:73:d9:60:25:19:74:32:fd:ea:ad: 36:7e:32:17:40:a3:23:0c:d5:a1:b2:52:72:db:3f:f7: df:b9:48:77:fa:51:bd:34:97:3d:e6:b1:88:bc:9a:62: a1:cc:16:94:a2:bf:f7:de:75:d2:a1:7b:c4:b1:13:a1 Exponent: 65537 (0x10001) Signed Extensions: Name: Certificate Authority Key Identifier Key ID: ee:73:03:59:87:0c:51:8c:9b:36:aa:1d:74:8f:82:d0: 33:25:c7:a5 Name: Authority Information Access Method: PKIX Online Certificate Status Protocol Location: URI: http://ipa.dev.example.com:80/ca/ocsp; Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Key Encipherment Data Encipherment Name: Extended Key Usage TLS Web Client Authentication Certificate E-Mail Protection Certificate Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Signature: b8:7f:79:4f:57:d2:43:65:63:a4:4c:81:59:a4:09:b4: 4d:86:02:52:cf:d5:0f:bc:5a:2f:6e:f9:f5:e6:6b:bf: a5:b7:c3:50:50:bd:a4:80:59:1d:75:4d:8a:f0:72:a7: 71:9d:85:7d:92:f4:98:ed:98:d7:f5:a8:60:b3:ce:b8: 8e:97:92:5a:85:c8:82:a5:08:36:71:9b:81:e2:7f:f8: 16:25:4e:0a:43:a5:14:c5:11:2c:99:e9:43:f6:91:e8: d8:f4:db:65:5d:56:33:3f:9f:17:02:31:35:8e:08:4a: 3a:aa:08:98:31:bb:a7:76:22:53:9d:f5:44:70:b8:92: d6:0a:b7:d3:51:9b:90:51:0d:2d:f8:8f:1d:4d:cc:5c: 1c:b4:ba:a5:c9:75:24:e1:ce:9b:66:f8:3d:e0:2f:d4: 05:87:56:46:5a:9b:6c:12:07:b1:be:14:8f:07:75:48: 5c:86:84:06:0c:bd:29:17:85:06:27:ae:6f:ee:c1:2b: 8a:bc:37:5f:c8:9d:81:bf:30:0f:c8:71:7e:e8:60:2c: 70:73:2d:84:1b:7d:38:31:63:41:e8:c3:ef:49:e1:3f: 33:48:7d:51:f5:c4:23:93:95:1a:7f:03:e8:e3:e3:21: 21:0a:54:b5:ab:81:a9:71:66:72:ad:d5:fe:6a:b5:37 Fingerprint (MD5): 33:DC:A2:A1:F4:86:9D:9B:F7:C3:6A:F6:94:85:76:35 Fingerprint (SHA1): B6:7E:21:CA:EE:45:50:C2:9A:6D:FE:88:A3:8C:D6:F8:B5:B7:70:C9 Certificate Trust Flags: SSL Flags: User Email Flags: User Object Signing Flags: Use # certutil -L -n testnick -d /tmp/tmp-aZzm2V Certificate: Data: Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption Issuer: CN=ipa.dev.example.com,O=2012-05-21 16:31:51 Validity: Not Before: Mon May 21 16:31:51 2012 Not After : Tue May 21 16:31:51 2013 Subject: CN=ipa.dev.example.com,O=2012-05-21 16:31:51 Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: b4:29:21:b3:8c:5c:a3:7c:17:8a:fe:3a:3a:9f:62:a6: 63:f1:7d:dc:b8:8c:10:a1:a1:ee:9d:40:a9:bf:69:d3: ec:f7:50:de:55:e4:cc:a0:8a:2a:2e:7e:be:80:18:5b: 08:f1:13:62:77:1c:48:c6:fb:68:a0:df:83:79:98:15: 28:91:55:4e:f8:be:4e:af:03:e0:1a:4c:72:a0:7a:07: 1c:35:61:82:28:4f:96:2b:8e:d2:62:17:54:8b:11:b9:
Re: [Freeipa-users] ipa ports
On 05/23/2012 05:40 PM, Jan-Frode Myklebust wrote: We have quite strict firewalls, so I need to specify the IPA network ports accurately. So, we have now opening for: 80/tcp, 88/tcp, 389/tcp, 443/tcp, 464/tcp, 636/tcp 88/udp, 464/udp in to our first IPA server. Now I'm in the process of configuring the first replica. Is there any other ports that needs to be opened between ipa master and replica? We don't serve NTP or DNS from IPA, so I guess these shouldn't be relevant, but I think we want dogtag replicated, so there's maybe some ports for that that needs opening ? Or, to put it another way, which of these ports: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Preparing_for_an_IPA_Installation.html#prereq-ports needs to be opened between ipa server, which for all clients, which for replica and which for administrative clients ? HTTP/HTTPS -- open for all LDAP/LDAPS -- open for all Kerberos-- open for all OCSP responder -- open for all if we use certs dogtag 9443 (agents)-- ? dogtag 9444 (users, SSL)-- ? dogtag 9445 (administrators)-- ? dogtag 9446 (users, client authentication) -- ? dogtag 9701 (Tomcat)-- ? dogtag 7389 (internal LDAP database) -- ? Dogtag ports are now proxied vial HTTP https://fedorahosted.org/freeipa/ticket/1334 I guess we need a doc bug to correct the documentation. Opened: https://bugzilla.redhat.com/show_bug.cgi?id=824666 Replica can check its connectivity to master it is created from using ipa-replica-conncheck utility on replica. It seems that this is not documented. Opened: https://bugzilla.redhat.com/show_bug.cgi?id=824667 -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] two way changes
Hi, Just windering but I thought that whether I did change son the original master, or on the replica that changes would flow to the other both ways? or do changes only flow original master to replica? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
