FIM SSPR - Portal can send e-mails, but SSPR gets "Unable to send a security code" RRS feed

  • Question

  • Hi all,

    In the middle of retrofitting a test environment with OTP in SSPR and while FIM Portal sends my new user notifications fine, I am having troubles sending out the one-time-codes.

    In SSPR, I enter the username, and it sits there for a while with a spinning wheel before erroring out with the message: Unable to send a security code.

    When I review Event logs, I can see that the e-mail sending is timing out:

    Any thoughts on why this might be? It works fine in production, but not in test - and the only difference between the two environments is that we're using EWS in Prod and SMTP relay in test... but again, I've verified the SMTP relay works.

    - Ross | MCTS: FIM 2010 | Now Offering ECMA1->ECMA2 Upgrade Services

    Wednesday, May 13, 2015 10:56 AM

All replies

  • Portal sends new user notifications to a manager, perhaps, whereas the one time code is sent to user?

    So, stupid question. Does the user have a valid email address? If yes, try sending an SMTP email via a command prompt.

    Nosh Mernacaj, Identity Management Specialist

    Wednesday, May 13, 2015 1:01 PM
  • To add to this, is the correct email address in the user attribute: msidmOneTimePasswordEmailAddress (you can view this in the extended attributes of a user)
    Wednesday, May 13, 2015 4:13 PM
  • The new user notifications being sent are directly to the user - they include setup details the user needs.

    And yes, can confirm the correct address is in the msidmOneTimePasswordEmailAddress field.

    I also just realised - my portal is running on HTTP in test, whereas the password reset is https. Could this be affecting it? | MCTS: FIM 2010 | Now Offering ECMA1->ECMA2 Upgrade Services

    Thursday, May 14, 2015 1:31 AM
  • I don't think the HTTPS has anything to do with it, but you can try to hit it with HTTP and see what happens.

    Nosh Mernacaj, Identity Management Specialist

    Thursday, May 14, 2015 12:53 PM
  • I can confirm... no joy with http.

    It is the FIM Service server that sends the OTP e-mail, right? | MCTS: FIM 2010 | Now Offering ECMA1->ECMA2 Upgrade Services

    Friday, May 15, 2015 1:00 AM
  • As far as I know, yes.

    Nosh Mernacaj, Identity Management Specialist

    Friday, May 15, 2015 1:10 PM
  • Did you ever find a solution to this problem?

    Did my post help? Please use "Vote As Helpful", "Mark as answer" or "Propose as answer". Thank you!

    Monday, November 7, 2016 2:21 PM
  • It was a while back, but honestly I don't think we ever did.

    I put it down to some unexplained networking issue, showed the client that everything should have been working and we progressed through to prod. Not ideal, but you just have to do these things sometimes unfortunately.

    One tool a colleague recently recommended is smtp4dev. Haven't used it yet, but the basic idea is that you throw it in your dev environment, where it keeps a record of any e-mails that were sent through its smtp server. Useful for validating things like one time passwords in a dev environment, particularly when you don't want live e-mails going to users. | MCTS: FIM 2010 | Now Offering ECMA1->ECMA2 Upgrade Services

    Tuesday, November 8, 2016 12:19 AM
  • There are some differences between normal email sending prosess and OTP email sending process. I noticed that in one customer case. Not sure what it is but definately there is something. We also got errors with OTP mails when normal emails sent ok. It was related to SMTP-relay and authentication against it. We fixed the problem using local SMTP-relay which forwards emails to the correct SMTP-relay.

    Hmm...I think FIM OTP email sending process tried to authenticate against the SMTP-relay even the SMTP-relay was "no need to authenticate" state.

    Monday, November 14, 2016 11:42 AM