kanakos.23654 (Customer) asked a question.
Questions Regarding Okta Login Using Email Address and User Profile Policy Settings
Dear Support Team,
Until now, our users have logged in to Okta using their first and last names. We would now like to allow users to log in using their email addresses as well.
We understand that this can be achieved by configuring a user profile policy. However, we have the following questions:
1. About setting User Permission to Read-Write
We understand that when creating a custom profile enrollment form, it is necessary to set User Permission to Read-Write in the Profile Editor.
In this case, if attributes such as first name, last name, and primary email address are set to Read-Write, does this mean that users will be able to modify these profile attributes themselves?
Could you please let us know what risks or issues may arise from changing User Permission to Read-Write?
2. About other settings related to self-registration and profile updates
We understand that after creating a user profile policy, it is possible to prevent users from self-registering accounts and entering attributes themselves by editing the policy under Security > User Profile Policies and setting both Self-Service Registration and Progressive Profiling to Deny on the Enrollment tab.
Are there any other settings that might still allow users to create accounts on their own or update their own profiles?
3. Difference between Active Directory users and Okta-created users
After creating a user profile policy, we checked whether the Sign Up option is shown on the login screen and whether profile editing is allowed, and we found a difference between users created in Active Directory and users created directly in Okta.
Is there a way to prevent profile editing for users created directly in Okta as well?
Our findings are as follows:
Users created in Active Directory
- Self-Service Registration: Deny
→ The Sign Up option is hidden on the login screen.
- Progressive Profiling: Disabled
→ Under Username > Account Settings > Account > Personal Information > Edit, users are unable to edit any fields other than the secondary email address.
Users created directly in Okta
- Self-Service Registration: Deny
→ The Sign Up option is hidden on the login screen.
- Progressive Profiling: Disabled
→ Under Username > Account Settings > Account > Personal Information > Edit, users are able to edit all fields except the Okta username and secondary email address.
We are referring to the documentation below.
Thank you very much for your support.
We would appreciate your guidance.
Best regards,
Kanako Seki
Hi @kanakos.23654 (Customer) , Thank you for reaching out to the Okta Community!
The differences you are observing between Active Directory-mastered users and Okta-created users stem from Okta's profile mastering feature. When a user is mastered by Active Directory, Okta enforces read-only restrictions on attributes sourced from AD. When a user is created directly in Okta, those same attributes default to read-write unless explicitly restricted in the profile editor.
Here are the answers to your questions:
Question 1: About setting User Permission to Read-Write
Yes, setting an attribute to Read-Write in the Profile Editor does allow users to modify those attributes themselves through their account settings. The primary risks and issues are:
To mitigate these risks, you could set critical attributes (first name, last name, primary email) to Read-Only in the Profile Editor unless there is a specific business requirement for users to modify them.
To be clear, if you actively plan to use the custom enrollment form to collect missing user data, you must accept the Read-Write behavior. However, because you noted in Question 2 that you plan to set both Self-Service Registration and Progressive Profiling to Deny, you might not actually need the enrollment form to collect those inputs.
Question 2: About other settings related to self-registration and profile updates
Setting both Self-Service Registration and Progressive Profiling to Deny in the User Profile Policy (under Security > User Profile Policies > Enrollment tab) is the primary control. However, there are additional settings to review:
Question 3: Difference between Active Directory users and Okta-created users
The behavior difference you observed is expected and is controlled by Okta's Profile & Lifecycle Mastering feature.
For Active Directory-mastered users:
When you enable Profile & Lifecycle Mastering for your Active Directory integration (Directory > Directory Integrations > Active Directory > Provisioning > To Okta > Profile & Lifecycle Mastering > check "Allow Active Directory to master Okta users"), Okta enforces read-only restrictions on all attributes sourced from AD. This is why users cannot edit first name, last name, or primary email: these attributes are mastered by AD, and Okta prevents local modifications to maintain data consistency with the source system.
For Okta-created users:
Users created directly in Okta are not mastered by any external system by default. Therefore, the Profile Editor settings control their editability. If you set attributes to Read-Write, Okta-created users can modify them. If you set them to Read-Only, they cannot.
To prevent profile editing for Okta-created users:
Some of the information mentioned can be referenced here:
I hope this clarifies the relationship between profile permissions, mastering, and the observed differences between user types. If you need further assistance with configurations specific to your environment, please open a case to discuss with our Okta Support colleagues.
If my answer helped, remember to mark it as best to increase its visibility for other members of the Okta Community who might have the same questions as you.
Hope my answer helps!
--
Help others in the community by liking or hitting Select as Best if this response helped you.
Securing AI agents across your org? Join our upcoming Ask Me Anything on 8/5 about Okta for AI Agents. Ask our expert questions.
Hi!
Thank you very much for your kind and detailed response. It was extremely helpful!
I also sincerely appreciate your attaching the reference materials.