Re: [Freeipa-users] IPA-adtrust and addition of replicas
On Tue, 03 Feb 2015, William wrote: Maybe something to test? You can create a user on the replica without ipa-adtrust-install and watch after replication on whether ipaNTSecurityIdentifier appeared in the user's object in LDAP. I was thinking more unit test or beaker test actually, but I'm sure I could do a setup by hand and test it later. Having a beaker test would be good. I was just thinking about proving that the flow is indeed what we are discussing. ;) This should be configured on replicas added to the network if adtrust has been run already. Perhaps this is something to consider also? Consistency through out the domain is a good thing. Exactly. Good suggestion. One thing we need to solve here is that enabling sidgen and other components will require installing Samba libraries. This is something to consider -- do we want these libraries (not daemons) installed on every master? Well, ipa-adtrust is a seperate package already isn't it? If you were in the position to be setting up an adtrust on freeipa, you would document that it should be installed on all hosts anyway, so then the adtrust package would pull in the adtrust libs. Once the adtrust is installed, be it trust controller or agent, perhaps this should be added into the domain services tree under cn=etc. That way, after the adtrust is run, you can see a list of hosts that do not yet have it installed, so that the trust agent can be configured on all other replicas. Additionally, adding a new replica could be hinted that if this exists to configure itself as a trust agent automatically as part of ipa-replica-install. Does that sound like a reasonable suggestion? Yes, this is what ipa-adtrust-install implements right now. My issue with this approach is the fact that we don't want to run smbd/winbindd/etc for trust agent case. Yet, ipa-adtrust-install forces packages to be installed and services to be active. Kind of what I meant but kind of not. I meant a more generic some adtrust agent or controller flag, rather than the services. The per host flag is to enable the detection of masters that lack adtrust agent or controller, rather than to detect if the domain has had adtrust run at all. My thought was more like: If I have three ipa masters, A B C. I have trust controller on A, and I am installing trust agent on B, I should post install receive a message: ipa-adtrust-install --agent: ... Install happens here ... The following masters are not agents or controllers. These should be promoted. * C To of course, prompt me to run adtrust-install on C. Then I add some host D, it should as part of ipa-replica-install be configured as a trust agent. This way the domain stays consistent and I am informed of the state of the network. This also means there should be a strategy for promotion of the agent to a controller, and also in the decommissioning code to remove both agent and installers correctly (If not already implemented) Makes sense. This will need to be added into a design page -- I'll work on that next week. There will be series of RFE tickets to correspond to work outlined in those design pages and this is a perfect example of an RFE. We can start with disabling ADTRUST and EXTID services on trust agents (these are smb and winbind in ipactl speak) and, maybe, rename them to something less confusing. Then we can decide whether not installing samba server packages would really be needed. Sounds like a good plan. Would this become a special case of ipa-adtrust-install? Or an option that is prompted for similar to the slapi-nis question. For most cases like this we have CLI option and ask for an answer interactively in case option wasn't provided explicitly and we are not running in unattended mode. In case of a slapi-nis it is driven by --enable-compat option of ipa-adtrust-install. The general calling pattern in ipa-adtrust-install is something like this: if not options.unattended and not options.enable_compat: options.enable_compat = enable_compat_tree() where enable_compat_tree() does ask user for a confirmation. -- / 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] IPA-adtrust and addition of replicas
On Tue, 03 Feb 2015, William wrote: Wow! From all this it really sounds like adding a replica in to an IPA domain where adtrust has been run could have a few edge cases. For example, what would happen if I create a new account on a replica without adtrust? Would sidgen run on the adtrust machine when it get's the record replicated to it? I think it might work. sidgen is a post operation and replication protocol uses normal ldap_*_ext() API to send new objects. Maybe something to test? You can create a user on the replica without ipa-adtrust-install and watch after replication on whether ipaNTSecurityIdentifier appeared in the user's object in LDAP. This should be configured on replicas added to the network if adtrust has been run already. Perhaps this is something to consider also? Consistency through out the domain is a good thing. Exactly. Good suggestion. One thing we need to solve here is that enabling sidgen and other components will require installing Samba libraries. This is something to consider -- do we want these libraries (not daemons) installed on every master? Well, ipa-adtrust is a seperate package already isn't it? If you were in the position to be setting up an adtrust on freeipa, you would document that it should be installed on all hosts anyway, so then the adtrust package would pull in the adtrust libs. Once the adtrust is installed, be it trust controller or agent, perhaps this should be added into the domain services tree under cn=etc. That way, after the adtrust is run, you can see a list of hosts that do not yet have it installed, so that the trust agent can be configured on all other replicas. Additionally, adding a new replica could be hinted that if this exists to configure itself as a trust agent automatically as part of ipa-replica-install. Does that sound like a reasonable suggestion? Yes, this is what ipa-adtrust-install implements right now. My issue with this approach is the fact that we don't want to run smbd/winbindd/etc for trust agent case. Yet, ipa-adtrust-install forces packages to be installed and services to be active. We can start with disabling ADTRUST and EXTID services on trust agents (these are smb and winbind in ipactl speak) and, maybe, rename them to something less confusing. Then we can decide whether not installing samba server packages would really be needed. -- / 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] IPA-adtrust and addition of replicas
Wow! From all this it really sounds like adding a replica in to an IPA domain where adtrust has been run could have a few edge cases. For example, what would happen if I create a new account on a replica without adtrust? Would sidgen run on the adtrust machine when it get's the record replicated to it? I think it might work. sidgen is a post operation and replication protocol uses normal ldap_*_ext() API to send new objects. Maybe something to test? What I realized now is that with FreeIPA 3.3+ we moved ID resolution fully to SSSD and we technically don't need to run full 'domain controller' stack (e.g. Samba) on a master that only wants to resolve IDs rather than participating in a balancing of the domain controller duties. What are the domain controller duties separate from the ID resolution tasks? What components carry out the id resolution? In discussing with Simo yesterday, we came to conclusion that we would call a 'full' master that provides features for trust as a 'trust controller'. Let's call the other configuration a 'trust agent'. A trust controller is a FreeIPA master which hosts: - LDAP server with sigden, extdom, and cldap plugins - KDC with IPA driver - Samba configured with ipasam PASSDB module - SSSD with ipa_server_mode=True - Global Catalog instance (a separate LDAP instance with an AD-compatible schema) A trust agent is a FreeIPA master which hosts - LDAP server with sigden and extdom - KDC with IPA driver - SSSD with ipa_server_mode=True As you can see, trus agent is a master that relies on SSSD to do resolution of IDs. Trust controller is used for managing trust: add trust agreements, enable/disable separate domains from a trusted forest to access FreeIPA resources, etc. Trust controller is also what Active Directory's domain controllers contact when validating the trust by means of SMB protocol using LSA calls which implies running a Samba server. This seems like a clean and logical separation. This should be configured on replicas added to the network if adtrust has been run already. Perhaps this is something to consider also? Consistency through out the domain is a good thing. Exactly. Good suggestion. One thing we need to solve here is that enabling sidgen and other components will require installing Samba libraries. This is something to consider -- do we want these libraries (not daemons) installed on every master? Well, ipa-adtrust is a seperate package already isn't it? If you were in the position to be setting up an adtrust on freeipa, you would document that it should be installed on all hosts anyway, so then the adtrust package would pull in the adtrust libs. Once the adtrust is installed, be it trust controller or agent, perhaps this should be added into the domain services tree under cn=etc. That way, after the adtrust is run, you can see a list of hosts that do not yet have it installed, so that the trust agent can be configured on all other replicas. Additionally, adding a new replica could be hinted that if this exists to configure itself as a trust agent automatically as part of ipa-replica-install. Does that sound like a reasonable suggestion? -- 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] IPA-adtrust and addition of replicas
On Mon, 02 Feb 2015, William wrote: On Sun, 2015-02-01 at 17:49 +0200, Alexander Bokovoy wrote: Hi, On Sun, 01 Feb 2015, William wrote: Hi, I have a single master instance of IPA 3.3.5 at the moment. I have configured this with IPA adtrust and run the adtrust preparation. I am about to add a second replica. The documentation[0][1] doesn't really go into what happens in this circumstance. Do I need to make any configuration on the replica once I have installed it? Or does the replica information file hint to the ipa-replica-installer that adtrust components must be configured? IE can my new replica act as a trust master, and will it correctly update attributes such as iPAntpassword? No, it will not. Although information about trust setup is in the replicated subtree, the plugins which get configured for the trust case are configured in cn=config which is not in the replicated subtree, thus they will need to be configured explicitly with ipa-adtrust-install on each replica which will provide services to IPA clients accessible by AD users. Password generation will be performed on such non-configured replica, though, because our password plugin will be able to generate ipaNTHash attribute for any user that has ipaNTSecurityIdentifier attribute. However, ipaNTSecurityIdentifier attribute is populated by sidgen plugin which is only activated when ipa-adtrust-install was run. Wow! From all this it really sounds like adding a replica in to an IPA domain where adtrust has been run could have a few edge cases. For example, what would happen if I create a new account on a replica without adtrust? Would sidgen run on the adtrust machine when it get's the record replicated to it? I think it might work. sidgen is a post operation and replication protocol uses normal ldap_*_ext() API to send new objects. What does one need to do to setup my new replica as a potential adtrust replica? For example, I am about to decommission my old master, so I would like the adtrust setup to available on the new master. Is it just a case of running the adtrust-install tool again? yes. Additionally, extdom plugin is what SSSD on IPA clients uses to request SID to name and name to SID resolution for AD users. It is also configured with the help of ipa-adtrust-install. Now, there is something interesting you've reminded me about by pointing to the ticket below: [0] http://www.freeipa.org/page/V3/MultipleTrustServers [1] https://fedorahosted.org/freeipa/ticket/2189 This ticket concerns enabling multiple IPA masters as domain controllers from Active Directory point of view. After running ipa-adtrust-install, the domain controllers will be advertised in the DNS service records and they will be contacted by AD DC at the point of validating trust (part of 'ipa trust-add' sequence). What I realized now is that with FreeIPA 3.3+ we moved ID resolution fully to SSSD and we technically don't need to run full 'domain controller' stack (e.g. Samba) on a master that only wants to resolve IDs rather than participating in a balancing of the domain controller duties. What are the domain controller duties separate from the ID resolution tasks? What components carry out the id resolution? In discussing with Simo yesterday, we came to conclusion that we would call a 'full' master that provides features for trust as a 'trust controller'. Let's call the other configuration a 'trust agent'. A trust controller is a FreeIPA master which hosts: - LDAP server with sigden, extdom, and cldap plugins - KDC with IPA driver - Samba configured with ipasam PASSDB module - SSSD with ipa_server_mode=True - Global Catalog instance (a separate LDAP instance with an AD-compatible schema) A trust agent is a FreeIPA master which hosts - LDAP server with sigden and extdom - KDC with IPA driver - SSSD with ipa_server_mode=True As you can see, trus agent is a master that relies on SSSD to do resolution of IDs. Trust controller is used for managing trust: add trust agreements, enable/disable separate domains from a trusted forest to access FreeIPA resources, etc. Trust controller is also what Active Directory's domain controllers contact when validating the trust by means of SMB protocol using LSA calls which implies running a Samba server. For such operation we could have a scaled-down version of ipa-adtrust-install which doesn't install Samba and configure it for use as a DC. Rather, it would install and configure required plugins (sidgen, extdom, but not cldap) to allow KDC to issue proper MS-PAC information to the master's host/fqdn@REALM key -- this is what will enable SSSD on the master to gain access to AD LDAP/Global Catalog over the trust. Such a lightweight configured 'domain controller' would only be able to resolve AD user/group identities but this is just what needed in majority of deployments. As result, with this approach we can also solve an issue of forced install of Samba on each master -- something we were looking to fix. This
Re: [Freeipa-users] IPA-adtrust and addition of replicas
Hi, On Sun, 01 Feb 2015, William wrote: Hi, I have a single master instance of IPA 3.3.5 at the moment. I have configured this with IPA adtrust and run the adtrust preparation. I am about to add a second replica. The documentation[0][1] doesn't really go into what happens in this circumstance. Do I need to make any configuration on the replica once I have installed it? Or does the replica information file hint to the ipa-replica-installer that adtrust components must be configured? IE can my new replica act as a trust master, and will it correctly update attributes such as iPAntpassword? No, it will not. Although information about trust setup is in the replicated subtree, the plugins which get configured for the trust case are configured in cn=config which is not in the replicated subtree, thus they will need to be configured explicitly with ipa-adtrust-install on each replica which will provide services to IPA clients accessible by AD users. Password generation will be performed on such non-configured replica, though, because our password plugin will be able to generate ipaNTHash attribute for any user that has ipaNTSecurityIdentifier attribute. However, ipaNTSecurityIdentifier attribute is populated by sidgen plugin which is only activated when ipa-adtrust-install was run. Additionally, extdom plugin is what SSSD on IPA clients uses to request SID to name and name to SID resolution for AD users. It is also configured with the help of ipa-adtrust-install. Now, there is something interesting you've reminded me about by pointing to the ticket below: [0] http://www.freeipa.org/page/V3/MultipleTrustServers [1] https://fedorahosted.org/freeipa/ticket/2189 This ticket concerns enabling multiple IPA masters as domain controllers from Active Directory point of view. After running ipa-adtrust-install, the domain controllers will be advertised in the DNS service records and they will be contacted by AD DC at the point of validating trust (part of 'ipa trust-add' sequence). What I realized now is that with FreeIPA 3.3+ we moved ID resolution fully to SSSD and we technically don't need to run full 'domain controller' stack (e.g. Samba) on a master that only wants to resolve IDs rather than participating in a balancing of the domain controller duties. For such operation we could have a scaled-down version of ipa-adtrust-install which doesn't install Samba and configure it for use as a DC. Rather, it would install and configure required plugins (sidgen, extdom, but not cldap) to allow KDC to issue proper MS-PAC information to the master's host/fqdn@REALM key -- this is what will enable SSSD on the master to gain access to AD LDAP/Global Catalog over the trust. Such a lightweight configured 'domain controller' would only be able to resolve AD user/group identities but this is just what needed in majority of deployments. As result, with this approach we can also solve an issue of forced install of Samba on each master -- something we were looking to fix. We would still need to make sure we are falling back to a proper master to act on trust-related management operations with IPA CLI and web UI because without enabled Samba on the master we wouldn't be able to establish trust at all (or change few other bits). -- / 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] IPA-adtrust and addition of replicas
On Sun, 2015-02-01 at 17:49 +0200, Alexander Bokovoy wrote: Hi, On Sun, 01 Feb 2015, William wrote: Hi, I have a single master instance of IPA 3.3.5 at the moment. I have configured this with IPA adtrust and run the adtrust preparation. I am about to add a second replica. The documentation[0][1] doesn't really go into what happens in this circumstance. Do I need to make any configuration on the replica once I have installed it? Or does the replica information file hint to the ipa-replica-installer that adtrust components must be configured? IE can my new replica act as a trust master, and will it correctly update attributes such as iPAntpassword? No, it will not. Although information about trust setup is in the replicated subtree, the plugins which get configured for the trust case are configured in cn=config which is not in the replicated subtree, thus they will need to be configured explicitly with ipa-adtrust-install on each replica which will provide services to IPA clients accessible by AD users. Password generation will be performed on such non-configured replica, though, because our password plugin will be able to generate ipaNTHash attribute for any user that has ipaNTSecurityIdentifier attribute. However, ipaNTSecurityIdentifier attribute is populated by sidgen plugin which is only activated when ipa-adtrust-install was run. Wow! From all this it really sounds like adding a replica in to an IPA domain where adtrust has been run could have a few edge cases. For example, what would happen if I create a new account on a replica without adtrust? Would sidgen run on the adtrust machine when it get's the record replicated to it? What does one need to do to setup my new replica as a potential adtrust replica? For example, I am about to decommission my old master, so I would like the adtrust setup to available on the new master. Is it just a case of running the adtrust-install tool again? Additionally, extdom plugin is what SSSD on IPA clients uses to request SID to name and name to SID resolution for AD users. It is also configured with the help of ipa-adtrust-install. Now, there is something interesting you've reminded me about by pointing to the ticket below: [0] http://www.freeipa.org/page/V3/MultipleTrustServers [1] https://fedorahosted.org/freeipa/ticket/2189 This ticket concerns enabling multiple IPA masters as domain controllers from Active Directory point of view. After running ipa-adtrust-install, the domain controllers will be advertised in the DNS service records and they will be contacted by AD DC at the point of validating trust (part of 'ipa trust-add' sequence). What I realized now is that with FreeIPA 3.3+ we moved ID resolution fully to SSSD and we technically don't need to run full 'domain controller' stack (e.g. Samba) on a master that only wants to resolve IDs rather than participating in a balancing of the domain controller duties. What are the domain controller duties separate from the ID resolution tasks? What components carry out the id resolution? For such operation we could have a scaled-down version of ipa-adtrust-install which doesn't install Samba and configure it for use as a DC. Rather, it would install and configure required plugins (sidgen, extdom, but not cldap) to allow KDC to issue proper MS-PAC information to the master's host/fqdn@REALM key -- this is what will enable SSSD on the master to gain access to AD LDAP/Global Catalog over the trust. Such a lightweight configured 'domain controller' would only be able to resolve AD user/group identities but this is just what needed in majority of deployments. As result, with this approach we can also solve an issue of forced install of Samba on each master -- something we were looking to fix. This should be configured on replicas added to the network if adtrust has been run already. Perhaps this is something to consider also? Consistency through out the domain is a good thing. We would still need to make sure we are falling back to a proper master to act on trust-related management operations with IPA CLI and web UI because without enabled Samba on the master we wouldn't be able to establish trust at all (or change few other bits). Thanks for your time. Sincerely, William -- 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] IPA-adtrust and addition of replicas
Hi, I have a single master instance of IPA 3.3.5 at the moment. I have configured this with IPA adtrust and run the adtrust preparation. I am about to add a second replica. The documentation[0][1] doesn't really go into what happens in this circumstance. Do I need to make any configuration on the replica once I have installed it? Or does the replica information file hint to the ipa-replica-installer that adtrust components must be configured? IE can my new replica act as a trust master, and will it correctly update attributes such as iPAntpassword? Sincerely, William [0] http://www.freeipa.org/page/V3/MultipleTrustServers [1] https://fedorahosted.org/freeipa/ticket/2189 -- 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
