none
SSPR Automatic User Registration - Encoding Issue RRS feed

  • Question

  • Hi,

    I'm using a script to programatically register SSPR users, it's based on the sspr script here:

    https://konab.com/automate-sspr-registration-fim-2010-r2/

    This scripts works fine, but I have an issue. HR provide me with an ASCII exported CSV file containing the answers. I convert the ASCII to unicode using notepad and import the file using a script (my script uses "-Encoding Unicode" with the import-CSV cmdlet. The problem I have is:

     When users type their SSPR answers in a web browser, if the answer has a space (i.e. " ") the response always fails, but if the user copies their answer from the input file, this works.

    I've tried modifying the input CSV file by doing a find and replace on white space by copying a single blank space and then doing a replace using a typed space and saving the file as Unicode. This has the opposite effect - if a user types their answer, it works, but if they do a copy and paste from the input source it fails.

    In summary, I want to give users the option of copying and pasting their SSPR answers, as well as typing them in directly - however I can't do that, it seems as if I'm hitting encoding issues somewhere. I've tried importing the file as ASCII but that's even worse - any answers with  space fail regardless of whether I type or copy the answer in.

    Any help appreciate, thanks.


    IT Support/Everything

    Saturday, December 20, 2014 9:21 AM

Answers

  • Hmmm... interesting. PowerShell (or .Net more generally) is quite good as retaining characters faithfully when changing the encoding, so it may not be anything to do with the ASCII v "Unicode" encoding. Is the original data sourced from a web page by any chance? If so, you may find that the spaces are actually non-break spaces (used commonly in web pages) which is a completely different character from a space. That would explain why copying and pasting works: the clipboard faithfully copies nbsp characters but of course the keyboard will output a standard (0x20 in ASCII) character. You could try opening the HR file in a hex editor to check, or, when inputting the data into FIM, instead of a space, type ALT0160 (using the numeric keypad).
    • Marked as answer by Aetius2012 Tuesday, January 6, 2015 11:40 AM
    Tuesday, January 6, 2015 10:37 AM

All replies

  • Ok, so I'm guessing no one else has come across this or similar FIM encoding issues?

    IT Support/Everything

    Sunday, December 21, 2014 6:15 PM
  • Well, first of all, why would you let anyone store their answers anywhere? Why do you need password reset questions in that case?

    What about your SQL server collation? Have you tried copy\pasting from the same file that you used to provision answers (the unicode one). From your workstation? From users workstations? From the workstation you ran your script? From the FIM box?


    The data above this text is pseudorandom, brace yourselves.

    Monday, December 22, 2014 2:05 PM
  • To answer the first question, it's a business requirement.

    Collation is - Latin1_General_CI_AS

    Yes, I've done a copy paste from 2 user PCs, the FIM server (which coincidentally is the server the script is ran from) and a random 2008 R2 server. All computers display the same pattern:

    - Either typing the answer works (if I do a find and replace on whitespace) prior to initially running the script
    or
    - copying and pasting the original answers works  (if I use the original input file without modification for my script)

    At no point am I able to perform a password reset on a user if their SSPR answer has 1 or more spaces by using both methods (typing and pasting)


    IT Support/Everything

    Wednesday, December 24, 2014 10:55 PM
  • Well, I've never seen anything like this before (and I hope I never will). At this point I may only thing about workarounds. Replace spaces with underscores. Try offering phone based password reset (new capability in MIM 2015, which is in beta now). Or you could use Azure Password Write Back feature if you have that implemented (AD to Azure integration that is).

    The data above this text is pseudorandom, brace yourselves.

    Friday, December 26, 2014 11:37 AM
  • Yup, I'd agree it's an oddity. The one thing I can say is that this behaviour is consistent, I've tried my input source data on a FIM lab environment and I get exactly the same thing.

    I suspect it's to do with the input data - the SSPR answers are sourced from a SAP system, then converted to CSV.


    IT Support/Everything

    Monday, December 29, 2014 11:56 AM
  • Hmmm... interesting. PowerShell (or .Net more generally) is quite good as retaining characters faithfully when changing the encoding, so it may not be anything to do with the ASCII v "Unicode" encoding. Is the original data sourced from a web page by any chance? If so, you may find that the spaces are actually non-break spaces (used commonly in web pages) which is a completely different character from a space. That would explain why copying and pasting works: the clipboard faithfully copies nbsp characters but of course the keyboard will output a standard (0x20 in ASCII) character. You could try opening the HR file in a hex editor to check, or, when inputting the data into FIM, instead of a space, type ALT0160 (using the numeric keypad).
    • Marked as answer by Aetius2012 Tuesday, January 6, 2015 11:40 AM
    Tuesday, January 6, 2015 10:37 AM
  • Thanks, using the hex editor revealed that FIM was in fact comparing a non-breaking space to a normal space and as such answering by typing, as well as using copy & paste would never work.


    IT Support/Everything

    Tuesday, January 6, 2015 11:40 AM
  • Hi Aetius, 

    Can you please provide me a script to register automatically through csv file. I am trying to find such way on internet but unable to find such.

    I'lll thankful to you, if you could help in this regard.


    F.

    Friday, June 14, 2019 7:20 AM