[Freeipa-devel] Adding a new DNA plugin configuration in IPAv3

[Simo Sorce]

On Wed, 2012-02-01 at 12:00 -0500, Dmitri Pal wrote:
> On 01/31/2012 06:45 AM, Sumit Bose wrote:
> > Hi,
> >
> > for the IPAv3 trust feature we have to add the objectclass
> > ipaNTUserAttrs/ipaNTGroupAttrs to every user/group which should be
> > visible on the Windows side of the trust. The only MUST attribute of
> > both objectclasses is ipaNTSecurityIdentifier the SID or the user or
> > group. We would like to manage the SIDS with the DNA plugin since they
> > have to be unique in the IPA domain.
> >
> > The trust support will typically be added to a running IPA domain,
> > because we do not plan to install it by default and we have to consider
> > updated v2 environments as well. So the question arises what is the most
> > preferred way to add a DNA configuration to an existing Directory Server
> > setup with replication.
> >
> > Nathan suggested to create the configuration with the full range on the
> > first master, configure the other master with no available values
> > and let the DNA plugin transfer the ranges between the masters.

This is the way to go.

> > This will lead to the following steps:
> >
> > 1. Check if there are already shared configuration entries in
> >    cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX
> >
> > 2a. if not we can create the initial configuration on the current
> >     master:
> >
> > dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
> > changetype: add
> > objectclass: top
> > objectclass: extensibleObject
> > cn: SIDs
> > dnaType: ipaNTSecurityIdentifier
> > dnaNextValue: 1000
> > dnaMaxValue: eval($SIDMAX)    # Maybe 200k ?
> > dnaMagicRegen: 999
> > dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs))
> > dnaScope: $SUFFIX
> > dnaThreshold: 500
> > dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX
> >
> > 3a. Add ipaNTUserAttrs/ipaNTGroupAttrs to all users/groups with
> >     ipaNTSecurityIdentifier=999 on the current master

This should be done as a task in Directory server.

> > 4a. Done on the first master

I am not sure I understand what does this means.

> > 2b. if there are already entries we can create the configuration for an
> >     additional master:
> >
> > dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
> > changetype: add
> > objectclass: top
> > objectclass: extensibleObject
> > cn: SIDs
> > dnaType: ipaNTSecurityIdentifier
> > dnaNextValue: 1101
> > dnaMaxValue: 1100
> > dnaMagicRegen: 999
> > dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs))
> > dnaScope: $SUFFIX
> > dnaThreshold: 500
> > dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX
> >
> > 3b. Done on the additional master, DNA plugin will sort out the rest
> >
> >
> >
> > Do these steps make sense?

Yes.

> > Is it necessary to add a lock to prevent a race condition btween step 1
> > and 2a, i.e. two admins try to prepare IPA for trusts independently at
> > the same time?

No, if admins are so dumb not to coordinate on adding this
infrastructure changing stuff and do it at the exact same moment it's
really their problem. We will, of course, document that they should be
careful.

> > Do I understand it correctly that if dnaMaxValue is set to e.g. 2^32 on
> > the first master, the range on the second master will start at 2^31? So
> > the usage of the full range will be quite sparse if dnaMaxValue is set
> > too high.

True, ranges are always split in half for now.

> > Step 3a on the first master might need some time to finish. Is it
> > necessary to set some kind of lock to prevent the configuration of the
> > DNA plugin on other masters while this task is running or is it safe to
> > add another master at any time?

safe, the task to add SIDs to users should be an explicit DS task set up
only by the ipa-trust-install script.

> > Are there other ways to introduce the DNA configuration? Nathan
> > suggested also that the ranges can be configured manually without
> > overlap, but if possible I would prefer the automatic way.

Automatic is better, less error prone.

> Couple comments.
> 1) What is the impact on the replication?

If you have many users the first replication would take a long time.

> 2) How we can prevent the case when in the distributed topology the
> change starts from two ends?

By documenting that you do not run ipa-trust-install on 2 ends.

> 3) What is the speed of the propagation of this configuration in a 20
> replica architecture?

It depends on the replica topology and what master you run the install
on.

> 4) Would it be better to generate the SIDs on every replica? We already
> have UID/GID and GUIDs for the entries. If SID is derived from entry
> GUID the change can be made locally and does not require replication.

SIDs cannot be derived from GUIDs.

> The GUIDs are already replicated so the SID can be generated locally
> like we do with the other non replicated attributes. In this case you
> just need to install a new plugin on your replicas and change
> configuration entry to enable it. As soon as this entry is replicated
> the plugin will kick in and would start adding SIDs to users and groups
> in the background on every replica. Overall there will be less traffic
> and no need to deal with DNA ranges. Is it possible to derive SID from
> other attribute in the User or group object?

We have thought about using uidNumber/gidNumber but the problem is that
in configurations where admins decide their values a uidNumber may
overlap numerically with a gidNumber of a normal group (User Private
groups would be excluded). This in turn would cause a user and a group
to have the same SID, which is very bad. The same issue would occur if
admins force identical uidNumbers/gidNumbers on users/groups.

Thinking more about it we could punt on creating the SID if such a
condition is detected, so it could still be a valid idea to use the
uid/gid as the RID for a SID, but it could cause confusion to not see
some groups/users show up without some way to warn when the internal
plugin finds such a conflict.

> 5) If we go with the way Summit suggested we also need to have a special
> handling in the ipa-replica-prepare depending upon whether the SID
> support is on or off.   

This is a very minor issue.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York