Hi @AdrianEgley,

This does appear to have the same behaviour in baseline 5.7U11 as well as latest of version 6. I know there were some changes made around the password areas in order to allow SSO in FSM.

I believe this may be a knock on affect of those changes whilst not be a direct change itself. This would then be why nothing is shown specifically for this in the notes.

Kind regards,

Lee Pinchbeck

Hi Lee,

We’ve always been able to use SSO in FSM since the version 5.2 days, hasn’t SSO always been allowed?

Are there any app params available to change the behaviour back? 

Or anyway to get the masked password value to return on a hierarchy select?

Simple XML Select.

<hierarchy_select>

  <primary_table>person</primary_table>

  <attrs>

    <attr>person.person_id</attr>

    <attr>person.password</attr>

  </attrs>

  <from>

    <table>person</table>

  </from>

  <where>

    <data_constraint>

      <constraint>

        <left_operand>person.person_id</left_operand>

        <operator>eq</operator>

        <right_operand>aegley</right_operand>

      </constraint>

    </data_constraint>

  </where>

</hierarchy_select>

With this the response.

<person_hierarchy_select_result result_name="">

  <person>

    <metrix_row_num>1</metrix_row_num>

    <person_id>AEGLEY</person_id>

  </person>

</person_hierarchy_select_result>

How do I get the password now?

Ady

Hi @AdrianEgley,

It has been there but there was further work done to improve upon it.

There may be something that could be done in metadata to bring this back but it may turn out to be deeper.

@Paul Drennan do you have any thoughts on this?

Kind regards,

Lee Pinchbeck

Ady, this was an intentional change as part of an outside security assessment. 5.7 Update 8 release notes:

Setting Up Person Records
Important. A change has been made to how Person records are set up that
affects who can change other user's passwords in FSM5.7u6.
A role identifies menus and functions that a person can and cannot access.
Functions are defined within each role and are used to determine what the
people with these roles can change and do. The ADMIN role is used for
administrators of FSM and are trusted to have full access to all Person
records and make changes to them. The functions EDITPERSONANY and
EDITROLEANY are assigned to anyone given the ADMIN role. The function
EDITPERSONANY enables administrators to edit license types and
passwords on Person records, and EDITROLEANY enables them to edit
roles.
 Person records can be created by non-admin users without these fields,
but an admin with EDITPERSONANY must set the license type and
passwords to activate the user and an admin with EDITROLEANY must
set the role of each person.
 Only an admin with the EDITPERSONANY function on their role can set
the license type and password for other users.
 Only an admin with the EDITROLEANY function on their role can
change the role for other users

These functions are automatically added to anyone with the ADMIN
role in FSM. These functions will also be given to anyone given an
ADMIN role during upgrades.
 Consider who has ADMIN roles currently in your company and who
you plan to assign ADMIN roles to and determine whether this
functionality is available to them.
Important. At least one Person record must be assigned the role named
ADMIN and also to any other administrators that edit Person or Role
records.
 Password and license type are no longer required fields on Person
records.
 Users can still change their own passwords.
For more information, see Security in the IFS Field Service Management
Reference Guide.
Critical Application Parameter Editing
An additional new function has been added to the ADMIN role,
IS_ADMIN_ROLE. This new function allows only your trusted
administrators to change values of critical application parameters. Please
see Security in the IFS Field Service Management Reference Guide for a list
of what parameters are included.
 This function is automatically added to anyone with the ADMIN role in
FSM. The functionality will also be given to anyone given an ADMIN
role during upgrades.
 Consider who has ADMIN roles currently in your company and who
you plan to assign ADMIN roles to and determine whether this
functionality should be available to them.
 Anyone with the IS_ADMIN_ROLE function can change the values in
critical parameters

Thanks @ChristineLaVoi,

I have seen that in the Release Notes and when removing and adding the functions to roles I can see how that works, so that’s all good.

With regards to getting the masked password value for the user is this possible via XML select? 

Regards

Ady

Ady, I’m sorry, but you are going to have to re-design this part of your solution.  It is no longer possible to retrieve the password hash via XML query.  You can retrieve it via SQL query, but it not usable for authentication as the hash itself is stored as an encrypted string in the database.  This is by design, and was done to improve security.  Unfortunately, what you have been doing (ad-hoc impersonation) is heavily frowned upon by security analysts because what made it possible is considered a security vulnerability.

I would store the encrypted password in a config file and have the process authenticate itself with the same ID/password each time, and send the person_id as a separate field.  Have a process update a field on the record with that person_id.

@Mike The FSM TechnoGeek Thanks for that Mike.

Glad we found it at this stage of the side project and update.

Thanks all for the replies.

Ady