Newbie Questions - Using Secondary Email (not organisation ones) for all password resets

[Burhan Loqueman]

Hi.

Is the following possible:

1) Setup PWM to use account data from a single Active Directory but use a secondary source database to store personal email contacts

2) Only use this personal email for all password reset/forgotton password OTP communications

If this is not possible, then can we

a) Populate a custom attribute field in AD using another system such as an IDM to populate the personal email address data from another source

b) forbid/prevent the user from changing this in PWM

c) get PWM to use only this secondary/personal email address for password resets

Basically I work at a College where we want to maintain control over the personal email address being used by staff / students for any password reset, and ideally only have these managed in our Student MIS and HR departments rather than directly by the user. We don't of course want to use their organisational email address at all as they may have locked themselves out of it!

[Robert Rust]

Burhan -

We have something similar set up, but our users still have the option to send the code to their institutional email account (that they generally wouldn't have access to if they need that page). We store the alternate email address in our Active Directory. We have a profile option that they are prompted to configure when first setting up the account, but you can certainly do it differently. I have the forgotten password email template set to send the recovery token to their alternate email address attribute.

-Robert

--
You received this message because you are subscribed to the Google Groups "pwm-general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pwm-general...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pwm-general/6c54ae52-2cdd-4ed4-8c9b-031bec83a6d5n%40googlegroups.com <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fpwm-general%2F6c54ae52-2cdd-4ed4-8c9b-031bec83a6d5n%2540googlegroups.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Crobert.j.rust%40uwrf.edu%7Ced40cdf88a534c9ca80b08d8b960dad2%7Cdbdf23c73f3a4bbeae76d7310a527fd8%7C1%7C0%7C637463172947376246%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=X5SugfClghvatWKK8VMHfFVpDKbuid2Y%2Fbbb%2BCWvMk0%3D&reserved=0>.

[Burhan Loqueman]

Useful info thank you

[Paul Suh]

Burhan,

I did just this sort of thing at a school where I worked a few years ago, using Windows Server 2016. There is an Active Directory schema attribute on the User object class called “E-mail-addresses” that you can populate and point PWM at for the password reset email. I no longer work there so I don’t have access to the exact configuration any more, but it worked well for us. I think we allowed users to self-edit the email address, but I recall that it was possible to lock out user changes.


—Paul

[Burhan Loqueman]

Thank you. I think I will opt for choosing to use one of the extensionAttribute fields which is free, get that populated from our MIS and not allow students to change / edit it. Main issue is to check that no one other than the user themself or an admin/account with permission to browse the AD and attributes, can read that attrib for GDPR reasons... will probably also limit this to students and not staff as I believe we will ahve issues with staff and lots of stored passwords on devices used for ActiveSync....

[Jason Everling]

There are multiple ways to restrict access, depends on which attribute you use and if its part of a default “AD” permission set. Like you, we have to hide data in AD to maintain compliance, we went with the “otherMailbox” and “mobile” attributes for PWM and had to do some changes on it, the Exchange extensionAttributes, never used those attributes before, but you can either set the “Confidential” bit if allowable or just set permissions to “Deny Read” for everyone except “SELF” and whoever else can read it. In order to get default attributes like “otherMailbox” and “mobile” from being globally readable we first had to remove the attributes from the property sets, property sets are groups of attributes with default permissions (security descriptors) that can’t be overridden except on each object itself which would be a nightmare to apply every time, you can see more of those here, https://docs.microsoft.com/en-us/windows/win32/adschema/property-sets , it is easy to remove them from the set, the attribute in schema will have “attributeSecurityGUID” set with a value, just clear out the value for the attribute and you can now set permissions and acl’s globally.

 

We do this so much for other items not PWM related and also have many custom attributes, we created security groups for the likes of GDPR and FERPA and assign permissions to those. I highly recommend you come up with a good strategy for future use as well for hiding needed data, it makes it so much easier.

--

You received this message because you are subscribed to the Google Groups "pwm-general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pwm-general...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pwm-general/b5e9c42d-fcca-4579-b2f0-a217524d1a76n%40googlegroups.com.