AD Account Password creation and delivery

[Markharoll (Marco Carolla)]

Hello Community,

We are working on an Active Directory (AD) integration project where we need to create new AD accounts with randomly generated, secure passwords. These passwords must then be delivered to the end-users for their initial login.

The specific requirements are:

• AD Account Creation: New AD accounts are to be created via SailPoint Identity Security Cloud (ISC).
• Random Password Generation: A strong, random password must be automatically generated during the account creation process.
• Password Delivery: The generated password must be delivered to the end-user. This is necessary for their initial login and to facilitate subsequent actions like setting up multi-factor authentication or security questions for password resets.
• No PowerShell Scripts: Due to explicit client requirements, we must avoid using PowerShell scripts for this process.

We are exploring the following approaches:

1. AfterCreate Rule:
   1.1 Implement an AfterCreate rule that generates a random password, sets it on the AD account, and then sends an email to the user with the password.
   1.2 Is this a viable approach? Are there any limitations or security considerations we should be aware of?

2. Password Interception:
   2.1 Attempt to intercept the generated password during the account creation process and then send it to the user via email.
   2.2 Is this technically possible? If so, what are the recommended methods and potential challenges?

If neither of these approaches is feasible, what are possible alternatives?

Thank you!

[ethompson (Edward Thompson)]

You can set the password with the AfterCreate rule, but technically this is done via a PowerShell script. See this example:

Send Password to user through email on new Active Directory(AD) account Creation

You can handle this in an AfterCreate or AfterModify (operation Enable for rehires) in PowerShell. Add-Type -AssemblyName System.Web $pass = ConvertTo-SecureString $([system.web.security.membership]::GeneratePassword(16, 2)) -AsPlainText -Force Set-ADAccountPassword -Identity $nativeIdentity -NewPassword $pass -Confirm:$false Set-ADUser $nativeIdentity -ChangePasswordAtLogon $true $BSTR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($pass) $Password = [System.Runtime.InteropServ…

[phil_awlings (Phil Rawlings)]

Create a random password during the AD CREATE, pull this back into ISC as an identity.attribute, then email it out to the line manager as part of the default account.create email template.

Simples.
Here’s the CREATE for you:

    {
      "object": {
        "id": "****",
        "name": "First Password",
        "type": "firstValid",
        "attributes": {
          "values": [
            {
              "type": "identityAttribute",
              "attributes": {
                "name": "firstPassword"
              }
            },
            {
              "type": "replaceAll",
              "attributes": {
                "input": {
                  "type": "randomAlphaNumeric",
                  "attributes": {
                    "length": 10
                  }
                },
                "table": {
                  "0": "2",
                  "1": "3",          ====>this bit just removes any confusion between 1/l etc
                  "l": "m",
                  "o": "p",
                  "O": "P"
                }
              }
            }
          ],
          "ignoreErrors": false
        },
        "internal": false
      }
    }

[ruben_elizondo]

Option 3 is the most secure, but as the article points out, it’s also the most inconvenient. Best Practices for Provisinoning with Passwords in IdentityNow

[Markharoll (Marco Carolla)]

Hi @phil_awlings ,

does your solution implies to explicitly write the password in to an Identity Attribute?

If so this solution must be discarded because the client wants to hide the password from anyone and email it to the appropriate user only

[Markharoll (Marco Carolla)]

Without a password users cannot proceed with the “Forgot Password” option.
This solution is not viable for us

[phil_awlings (Phil Rawlings)]

Hi Marco,
Yes it writes it explicitly to the identity.attribute which can be read by ISC Admins (maybe helpdesk too).

Maybe Powershell is the solution that you are looking for

[ruben_elizondo]

Hello Marco, there would be a password, it would be set on account creation. It would be random and unknown to anyone.

The user would set their own password through the “forgot my password” flow. There would be no need to ever send the clear text password in any communication. The user would need to validate themselves through the MFA options configured before setting it.

Bests,
Ruben

[Markharoll (Marco Carolla)]

Hi @ruben_elizondo the user cannot set the MFA beforehand since the account does not exist yet. The first step must be a login and a reset password.

[Markharoll (Marco Carolla)]

I just found this Supported Feature for the EntraID connector: Multi Factor Authentication (MFA).

Is it possible to achieve the following scenario?

1. A new user joins the company and, as part of the onboarding process, a new EntraID account is created for him
2. ISC sets a random unknown password with a generator in the “Source > Create Account” section
3. ISC automatically sets the MFA based on some connector configurations
4. When the user first logins, he would find his MFA already configured and will be able to perform a password reset to login

Would this be correct?

[ruben_elizondo]

@Markharoll , Let me go through a couple of flows to better explain some approaches you can consider.

Are you using passthru authentication for these identities with Active Directory as the authentication source?

If so, then the flow would look like this (with some assumptions called out)

1. HR aggregation - > new identity is created.
2. An active directory account is created for them with a randomized unknown password.
3. An invitation email would be sent to them, they would not be asked to set a password because ISC already has one for them, even though the user doesn’t know it at this point.
4. On the ISC sign in page they would use the forgot my password option.
5. They would be presented with MFA options where they will receive a code. Assumption: these options, i.e. email, alternate email, mobile, ect. would already be populated on the identity from attributes in the HR source.
6. The user will set a new password for ISC which will be set on Active Directory since this is the authentication source.This is now their password for AD and ISC by virtue of the PassThru Auth.

If you are not using PassThru authentication. The you can use the password management feature. The flow be the same as the first scenario for steps 1-2.

3. The invitation link would allow them to register, set a password for ISC and add in KBA.
4. From their Home page, they would choose “managed passwords” > active directory application > change password. The assumption here is that you have set up Active directory as an application to allow users to use the password management feature.
5. They can then enter a new password without having to enter the old one.
6. ISC would update the password in Active Directory.

To answer your question though, yes, you can set the MFA attributes on the account create policy just as you noted.

“When the user first logins, he would find his MFA already configured and will be able to perform a password reset to login” - that is correct. I’m assuming that you user is logging into Entra in this scenario.

Hope this helps,
Ruben

[Markharoll (Marco Carolla)]

This is great, thank you!
Since you mentioned PTA or Password Management addon, the client prefers the “Service Provider” functionality since it allows to automatically set the same login to all users. Moreover, the Password Management addon has not been purchased so it’s not available for us.

What about SSO with the Service Provider functionality for my previous scenario?
Let me add some important details:

1. We configure the SSO in ISC via “Admin > Global > Security Settings > Service Provider”. The login to ISC will now require users to authenticate with their EntraID credentials
2. When a new user joins the company and, as part of the onboarding process, a new EntraID account is created for him (i.e. with a dynamic Role)
3. ISC sets a random unknown password with a generator in the “Source of EntraID > Create Account” section.
4. ISC automatically sets the MFA based on some EntraID connector configurations. The configurations will be set according to user data aggregated from the Joiner process (i.e. primary email, secondary email, phone, …)
5. When the user first logins, he would find the EntraID login page instead of SailPoint’s.
6. Since the user does not know his password, he will have to follow the “Forgot Password” procedure.
7. At this point his MFA would already be configured and he will be able to perform a password reset to login

Is this scenario possible?

[ruben_elizondo]

@Markharoll , that’s my understanding yes. SailPoint’s part ends at provisioning the MFA attributes, the rest is really EntraId native capabilities.

When you mentioned they prefered ‘the “Service Provider” functionality since it allows to automatically set the same login to all users’, I assume you are just referring to the SSO experience.

Speaking of logins, you will want to make sure to communicate these instructions and their login id to the users in the welcome email or new account email since with a generator it may not be a straight forward first.last@domain but may have a counter incremented. Or I suppose, you can provide that information to their manager if they can’t access their work email until they get onto the SSO.

That is a much more secure posture than emailing a password (even if the psswd is a temporary one). Good luck!