• State Not Answered
  • Locked Locked
  • Replies 1 reply
  • Subscribers 37 subscribers
  • Views 4903 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Custom AD Attributes for Authentication with PM

Charles
over 7 years ago

Hey there,

Is this scenario possible?

  1. Custom application collects information – e.g. Dog's Name, Employee ID.
  2. Collected information is pushed directly Password Manager as the answers to mandatory questions – e.g. "What is your Dog's name?"
  3. New users can then authenticate using that information rather than having to do the first time self-registration.

If that's not possible, what about this?

  1. Custom application collects information.
  2. Information is placed in AD attributes (extensionAttribute10, employeeID).
  3. Password Manager uses those fields to authenticate those users rather its own internal data.
  4. New users can then authenticate using this information rather than having to do the first time self-registration.

The problem we're trying to solve is because not everyone does the self-registration, they're not able to use password manager when they need it the most. They end up going to our help desk for a passcode, then they can register, and then they can reset their password.

If we can have it so that PM is using already available information to authenticate, then we can cut out the voluntary self-registration and the help desk call.

Thanks for your time!

Charles

Parents
  • 0 over 7 years ago

    I would raise concern on the suggested scenario: security. PM is not primary Authentication master, but to serve as a secondary secure "back-door" for temp authentication (exposed to internet) to do very narrow tasks (reset password, unlock) and *deny* the rest.
    (a) AD (primary Authentication master) stored user password in secure one-way encryption in DC private highly protected Windows OS area.
    (b) PM stored Q/A in one-way encrypted way in regular AD Attribute (no protected as high as (a), same issue as SIDHistory during migration). Therefore all activity via PM is subject of higher on-going monitoring (audit/report/alert/notification). And the changes allowed are very limited (password change, unlock)
    Your scenario: is to store *unencrypted* password in AD unprotected attribute - is similar to the one "write password on piece on paper attached to the computer screen".

Reply
  • 0 over 7 years ago

    I would raise concern on the suggested scenario: security. PM is not primary Authentication master, but to serve as a secondary secure "back-door" for temp authentication (exposed to internet) to do very narrow tasks (reset password, unlock) and *deny* the rest.
    (a) AD (primary Authentication master) stored user password in secure one-way encryption in DC private highly protected Windows OS area.
    (b) PM stored Q/A in one-way encrypted way in regular AD Attribute (no protected as high as (a), same issue as SIDHistory during migration). Therefore all activity via PM is subject of higher on-going monitoring (audit/report/alert/notification). And the changes allowed are very limited (password change, unlock)
    Your scenario: is to store *unencrypted* password in AD unprotected attribute - is similar to the one "write password on piece on paper attached to the computer screen".

Children
No Data