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 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

4a. Done on the first master

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?

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?

There is no locking/notification mechansim to do this AFAIK.

The "first master" in this case really means the first one that gets updated packages. The updates that happen at rpm upgrade time happen with the server listening only on ldapi so it would be very possible for two servers to apply the updates at the same time without knowing it.


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.

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?

In fact it might take a REALLY long time if there are a lot of users. This would happen at the end of an rpm upgrade, I wonder if we'd want a separate task to run instead.

If we can figure out a way to have only one server do all the updates then I don't think the DNA config would be an issue.

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.

I think coordinating manual ranges would be hard, I agree with Sumit that automatic is the way to go.

I wonder if before shutting things down for upgrade something creates cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX and sets a magic value in it specific to the host that added it.

When any other changes are done relating to this update if the hostname doesn't match that magic value the updates are skipped.

We tend to construct full dns for reference rather than searching so I'd think that even if there was a replication conflict entry created it would never get used because of the unique dn it would get.

rob

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to