Re: [Freeipa-users] IPA-adtrust and addition of replicas

2015-02-04 Thread Alexander Bokovoy

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

2015-02-02 Thread Alexander Bokovoy

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

2015-02-02 Thread William

 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

2015-02-02 Thread Alexander Bokovoy

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

2015-02-01 Thread Alexander Bokovoy

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

2015-02-01 Thread William
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