"Password never expires" greyed out?

You may need to Create a Fine Grained Password Policy

First, make sure you have already created Management VM:

https://docs.microsoft.com/en-us/azure/active-directory-domain-services/tutorial-create-management-vm

You can set the password policies in the domain by opening the "Active Directory Administrative Center and Create Fine Grained Password Policies . A guide can be found here:

https://activedirectorypro.com/create-fine-grained-password-policies/

If the users are logging to O365 using their Azure AD accounts, then the investigation should start on the Azure AD front, however.

It is not clear where the user password verification is happening:

• If you're using Password Hash Sync: check the current password policies you have on Azure AD: https://docs.microsoft.com/en-us/microsoft-365/admin/add-users/set-password-to-never-expire?view=o365-worldwide
• If you're using ADFS/Pass-through Authentication: Check your local domain password policies, or the ADFS server, or the Pass-through authentication agent.

I highly doubt this is related, but because an expired password on AADDS should not effect O365: but it's worth working on this as well: https://docs.microsoft.com/en-us/azure/active-directory-domain-services/password-policy

Are you using directory synchronization (AD Connect) between your AD and Azure AD? This is the key question here.

If the user account comes from AD, then password expiration (and authentication in general) is managed by your on-premises AD; if instead the user account is native to Azure AD, everything is managed from there.

Since you showed a screenshot for the user account in ADUC, I'm assuming the user account exists in AD and is synchronized to Azure AD; in this case, it's correct to set user account properties (such as password never expiring) from AD; Azure AD will not have any role in this, because on-premises AD is the main source of user account information.

Now, why do you have those options grayed out? This looks indeed like a permission issue; Active Directory Users and Computers (AUDC for short) will happily let anyone (authenticated) look at AD data, but if you are not allowed to perform an operation, it will be grayed out or not even shown at all.

If you see an object in AD that you can't edit, or if you try to edit it and get an "access denied" error, this means you don't have enough permissions to do that.
When you are a domain admin (and actually acting as such, because UAC can be a royal pain) you should be able to edit anything. But this is still a matter of permissions: domain admins are allowed to edit anything because the right to do so is automatically granted to the "Domain Admins" group. If someone changed permissions on a OU or the user object itself and removed the default "Domain Admins have full control" access right, you'll be blocked from touching it.

Bottom line: check permissions on the user object (and/or on the OU where it's located) and make sure "Domain Admins" have full control. If this is not the case, get it forcibly; Domain Admins are always allowed to take ownership of anything they don't own.