#3635 Warning needed when re-adding trust with a different range
Closed: Fixed None Opened 10 years ago by steeve.

When trust is deleted the trust range is kept to make sure the same range is used in case trust is re-added. But, if re-adding a trust with --base-id/range-size a warning, which says that an old range exists for the domain being trusted or a question if you want to continue with the new range (deleting the old range) or use the old range, would be useful.

# ipa trust-del adlabs.com
--------------------------
Deleted trust "adlabs.com"
--------------------------

# ipa idrange-find
----------------
2 ranges matched
----------------
  Range name: ADLABS.COM_id_range
  First Posix ID of the range: 1436799999
  Number of IDs in the range: 1177
  First RID of the corresponding RID range: 0
  Domain SID of the trusted domain: S-1-5-21-3069109027-1612402048-776712048
  Range type: Active Directory domain range

  Range name: TESTRELM.COM_id_range
  First Posix ID of the range: 1155200000
  Number of IDs in the range: 18
  First RID of the corresponding RID range: 1000
  First RID of the secondary RID range: 99999999
  Range type: local domain range
----------------------------
Number of entries returned 2
----------------------------

# /usr/bin/ipa trust-add --type=ad adlabs.com --admin administrator --password --base-id=1155300028
Active directory domain administrator's password:
---------------------------------------------------
Added Active Directory trust for realm "adlabs.com"
---------------------------------------------------
  Realm name: adlabs.com
  Domain NetBIOS name: ADLABS
  Domain Security Identifier: S-1-5-21-3069109027-1612402048-776712048
  SID blacklist incoming: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5,
                          S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13,
                          S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20
  SID blacklist outgoing: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5,
                          S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13,
                          S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20
  Trust direction: Two-way trust
  Trust type: Active Directory domain
  Trust status: Established and verified

# ipa idrange-find
----------------
2 ranges matched
----------------
  Range name: ADLABS.COM_id_range
  First Posix ID of the range: 1436799999
  Number of IDs in the range: 1177
  First RID of the corresponding RID range: 0
  Domain SID of the trusted domain: S-1-5-21-3069109027-1612402048-776712048
  Range type: Active Directory domain range

  Range name: TESTRELM.COM_id_range
  First Posix ID of the range: 1155200000
  Number of IDs in the range: 18
  First RID of the corresponding RID range: 1000
  First RID of the secondary RID range: 99999999
  Range type: local domain range
----------------------------
Number of entries returned 2
----------------------------

We may rather consider raising an error as --base-id=1155300028 is not used at all in this case. Users would need to delete the range before specifying a custom range base in trust-add.

Adding Sumit to CC, do you think we should purpose solution proposed in description or comment:2?

Replying to [comment:4 mkosek]:

Adding Sumit to CC, do you think we should purpose solution proposed in description or comment:2?

Yes, I think it is best to stop with an error before the trust is added. The error message should explain that there already are one or more idranges for this domain and that either they must be remove of the --base-id option should be dropped. This would fix best with the current usage of the ipa cli, because iirc the ipa cli utilities only ask interactively for missing mandatory arguments but do not ask the user what to do next.

Rename "trusts" component to "Trusts" to achieve correct sorting.

Metadata Update from @steeve:
- Issue assigned to akrivoka
- Issue set to the milestone: FreeIPA 3.3 - 2013/06

7 years ago

Login to comment on this ticket.

Metadata