Re: [Freeipa-devel] Adding a new DNA plugin configuration in IPAv3
On Wed, Feb 01, 2012 at 01:59:15PM -0500, Simo Sorce wrote: 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
Re: [Freeipa-devel] Adding a new DNA plugin configuration in IPAv3
On Thu, 02 Feb 2012, Sumit Bose wrote: Simo, thank you for give detailed responses and explanations here. To make it - hopefully - even clearer I try to describe the step that are necessary to enable IPA for trust and to create trust to AD domains. I assume that we start from a running IPAv2 setup with replication: 1. Update IPA to v3, install the new packages, run everything that is needed for the update. This step will not create anything related to trust (only the needed python code and config file templates are installed) 2. Call ipa-adtrust-install to enable IPA to handle trust, this will - create the samba configuration - add cn=trust to the DIT - generate a domain SID and stores it in the DIT - add the well know administrator and admin group SIDs to the admin user and the admins group respectively - activate the CLDAP directory server plugin - add DNA configuration to automatically add SIDs to users and groups on the server where ipa-adtrust-install At this point 'ipa trust ...' set of commands mentioned in (5) will be able to operate because we'll have enough information about our own domain to proceed with trusts to other domains. 3. Now SIDs can be added to users and groups, this can be done - as Simo mentioned above with the help of a directory server task to generate them as fast a possible - but if there are concerns about the traffic caused by the replication, this can also be done by an external script, with a rate limitation or during non-office hours this process might take some time, but since it has to be done only once I think it is even acceptable if it needs some days to finish, as long as it is documented :-) Agree. There are two separate phases here, actually: - trust creation - trust usage Normal usage is possible after step (3), creating trusts is possible before (3), albeight it wouldn't be quite usable besides administrator account. 4. Now ipa-adtrust-install can be called on other IPA servers which will now skip the configuration steps which can already be found in the replicated tree, some of the remaining ones are: - create the samba configuration - activate the CLDAP directory server plugin - add SID DNA configuration with an empty range ACK. There is also need to add DNS records to get these IPA servers in use for AD discovery. 5. Finally a trust to an AD domain can be created my calling 'net rpc trust create ...' (Alexander is working on the integration into the ipa utility so that it will be more like 'ipa adtrust-create' or similar). Yep. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Adding a new DNA plugin configuration in IPAv3
On Thu, 2012-02-02 at 13:39 +0200, Alexander Bokovoy wrote: On Thu, 02 Feb 2012, Sumit Bose wrote: Simo, thank you for give detailed responses and explanations here. To make it - hopefully - even clearer I try to describe the step that are necessary to enable IPA for trust and to create trust to AD domains. I assume that we start from a running IPAv2 setup with replication: 1. Update IPA to v3, install the new packages, run everything that is needed for the update. This step will not create anything related to trust (only the needed python code and config file templates are installed) 2. Call ipa-adtrust-install to enable IPA to handle trust, this will - create the samba configuration - add cn=trust to the DIT - generate a domain SID and stores it in the DIT - add the well know administrator and admin group SIDs to the admin user and the admins group respectively - activate the CLDAP directory server plugin - add DNA configuration to automatically add SIDs to users and groups on the server where ipa-adtrust-install At this point 'ipa trust ...' set of commands mentioned in (5) will be able to operate because we'll have enough information about our own domain to proceed with trusts to other domains. 3. Now SIDs can be added to users and groups, this can be done - as Simo mentioned above with the help of a directory server task to generate them as fast a possible - but if there are concerns about the traffic caused by the replication, this can also be done by an external script, with a rate limitation or during non-office hours this process might take some time, but since it has to be done only once I think it is even acceptable if it needs some days to finish, as long as it is documented :-) Agree. There are two separate phases here, actually: - trust creation - trust usage Normal usage is possible after step (3), creating trusts is possible before (3), albeight it wouldn't be quite usable besides administrator account. 4. Now ipa-adtrust-install can be called on other IPA servers which will now skip the configuration steps which can already be found in the replicated tree, some of the remaining ones are: - create the samba configuration - activate the CLDAP directory server plugin - add SID DNA configuration with an empty range ACK. There is also need to add DNS records to get these IPA servers in use for AD discovery. This is actually critical, the other servers need to have the DNA plugin properly configured, otherwise creating a user on another server will not add the SID, and we will have some users missing them. So I am thinking that we have 2 strategies here: - Require we run a ipa-trust-prepare script on all masters before we populate users - Add a new plugin, enabled by default at upgrade time, that is able to detect trust were activated, and when that happens it automatically adds the CLDAP and DNA plugins needed configuration. There is also the problem of the samba configuration (Still the server will need a restart so it is not a complete solution I guess). The second would be nice, but it seem a lot more complex than what we can afford for a first release and still has some gotchas. Also we need to consider that we may not want to make all servers expose samba and cldap. In most cases admins would want to enable only servers that are close to the AD domain they want to trust. So we need the DNA plugin configured everywhere, because it works at user creation, but we need to be able to *not* configure samba, cldap (and _msdcs DNS records) where not wanted. We will also need a way to show which servers are 'trust' enabled so that admins can easily inspect their setup. 5. Finally a trust to an AD domain can be created my calling 'net rpc trust create ...' (Alexander is working on the integration into the ipa utility so that it will be more like 'ipa adtrust-create' or similar). Yep. ack to all the rest. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Adding a new DNA plugin configuration in IPAv3
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 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? 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? 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. Thank you for your help. bye, Sumit ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Couple comments. 1) What is the impact on the replication? 2) How we can prevent the case when in the distributed topology the change starts from two ends? 3) What is the speed of the propagation of this configuration in a 20 replica architecture? 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. 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? 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. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Adding a new DNA plugin configuration in IPAv3
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
Re: [Freeipa-devel] Adding a new DNA plugin configuration in IPAv3
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
Re: [Freeipa-devel] Adding a new DNA plugin configuration in IPAv3
On Wed, 2012-02-01 at 13:39 -0500, Rob Crittenden wrote: 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. The trust stuff is always explicitly installed manually, so there is no problem at rpm upgrade time. Either the configuration is already there or there is no configuration to care about. 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. Nothing to do at rpm updagrade time. 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. Only one server should do them see my other email. 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. I don't think this is necessary, it does not avoid races anyways. Simo. -- Simo Sorce * Red Hat, Inc *
[Freeipa-devel] Adding a new DNA plugin configuration in IPAv3
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? 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? 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. Thank you for your help. bye, Sumit ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
