00ukhdzxyeqDysyVi0h71.556148626674291E12 (Customer) asked a question.
I currently have some code like this
var request = new CreateUserWithProviderOptions
{
Activate = true,
Profile = new UserProfile
{
Email = eMailAddress,
FirstName = firstName,
LastName = lastName,
Login = eMailAddress
},
ProviderName = "<redacted>,
ProviderType = AuthenticationProviderType.Ldap
};
var oktaClient = new OktaClient(new OktaClientConfiguration
{
OktaDomain = "https://<redacted>.oktapreview.com",
Token = "<redacted>"
});
var user = await oktaClient.Users.CreateUserAsync(request);
This is working fine to create the user in Okta mastered to our LDAP provider and activating the user which sends out an e-mail. How can I suppress the activation e-mail and not require the use to set their password? We would like the use to login with their existing LDAP password and not be forced to set/change it.
When we JIT a user mastered to LDAP we are already suppressing the e-mail and they are logged in using their existing LDAP password, they aren't forced to set/change it. We have a use case where we need to create some users ahead of time through the Okta SDK and we want these users to have the same experience.
I'm not a developer, but I'm curious... if the user ignores the activation email and just tries to sign in at the login page, will he authenticate to your LDAP provider, or does Okta force him to set a password? If Okta's asking him to set a password, it sounds like it's not recognizing that the user is associated with an external provider.
Looking around on the developer site, I found this section that gives an example of how to create a user with an authentication provider. Your code appears to set all the same parameters except the "provider=true" parameter on the last line. Could that be significant?
I'm using the Okta SDK to call the API, the oktaClient.Users.CreateUserAsync part. That call in the SDK should be setting the provider=true query parameter in the URL since I'm calling CreateUserAsync with the CreateUserWithProviderOptions type. I haven't ran a sniffer like Fiddler or something to verify that, but I would not have control of setting a query parameter in the HTTP address since I"m calling the endpoint through the SDK.
Okta does allow the user to login with their existing current LDAP credentials, even though the e-mail is sent. The LDAP provider is wired up correctly for the user, we just don't want to send them the e-mail as we don't want them to reset their password when enabling Okta and it is confusing to the user in our workflow. We can turn this e-mail off for JIT created uses, but I can't figure out how to suppress it if we create a user through the APIs/SDK.