The aggregation is a wrong choice, a LeaseAgreement is not made up of Person

You are right when considering the real world as the standard. In my opinion, it would be better to consider the software requirements as the standard. After all, UML class diagrams are used to model software architectures.

Notice tenant is shown both as an attribute and a relation's role, making the diagram unnecessarily complex.

Thanks for pointing that out. So, either an attribute or a relation's role, but not both?

Sorry, I misspoke earlier. The LeaseAgreement should actually only contain one person, the tenant. For this, the Person class has the attribute tenant. However, instances of the Person type should not contain any attributes of the LeaseAgreement type. A Person instance should have no knowledge of the LeaseAgreement instances that reference it. Therefore, I would set the multiplicity to 0 on the LeaseAgreement side.

Now, someone suggested that I should still represent the multiplicity as 0..* on the LeaseAgreement side. However, in my opinion, this doesn't make sense. 0..* on the LeaseAgreement side would mean that Person instances own a collection of LeaseAgreements. I hope I was able to clear up the confusion.