locked
Extranet Self Service Reset Portal for OTP Mail only via FIM to an untrusted AD RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi all,

    I'm busy with architects designing on a new scenario for me in FIM 2010 R2 Password reset Portal.
    We have an existing FIM setup in our internal coperate AD Domain without any existing password reset/registration.

    I've got to manage an AD (not domain- or forest-trusted) containing external users (no problem for the AD MA). The idea is to provide the FIM Password Reset Portal functionality to those users (I've got their email address):
    - Once a new user is created in that seperate AD, create an OTP via mail to that user to ask to set a password.
    - Allow the users to ask for an OTP via mail on request (forgot my password) via reverse proxy (extranet scenario).
    - There is no functional need for registering secrets in the self service  (FIM registration NOT wanted/needed)

    I'm not sure before proceeding if this is possible:
    - is only OTP mail possible, without using the registering in FIM? (I think yes)
    - can I set the password of a user of an external domain, without trust: this means does a reset go 100% via FIM, and there is no trust in the IIS required somehow to that domain?  

    I've seen the interesting video http://www.youtube.com/watch?v=T-p41Ze9ewA but I want to be sure.

    Thanks for the reply and suggestions
    David.
    PS: anyone of you ever connected to DB2 on a Mainframe via the FIM DB2 MA?

    Monday, September 23, 2013 7:38 AM

All replies

  • Question
    Sign in to vote
    1
    Sign in to vote

    I'm not sure if this functionality is used a lot (in this scenario), seeing no confirmation on this approach.

    Friday, September 27, 2013 9:11 AM
  • Question
    Sign in to vote
    3
    Sign in to vote
    for the users in the external AD to be able to use the SSPR feature within FIM, those users must be known within the FIM portal and the attribute holding the mail of the user (msidmonetimepasswordemailadress) must be populated. The forest with FIM must also have a trust with the external users AD so that those users can use the FIM portal and therefore SSPR

    Jorge de Almeida Pinto [MVP-DS] | Principal Consultant | BLOG: http://jorgequestforknowledge.wordpress.com/

    Saturday, October 5, 2013 7:45 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    As long as the users are programmatically registered for FIM SSPR (i.e., they do not need to login to the FIM SSPR enrollment site, and you programmatically enroll each user even though they may not need to fill out any of the enrollment templates' fields) this email-only (or SMS-only) scenario will very likely work in the absence of any AD trusts.

    Steve Kradel, Zetetic LLC

    Monday, October 7, 2013 4:00 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Both Jorge and Steve thanks for the reply.

    I will test this in a Lab environment and I'll give feedback in this thread.


    Monday, October 7, 2013 9:06 AM
  • Question
    Sign in to vote
    1
    Sign in to vote

    The object of the user MUST exist within FIM with at least domain and sAMAccountName. I'm not sure the objectSID is needed or not. With regards to FIM, no SSPR registration is also not needed IF you are using either the SMS gate of the mail gate. SSPR registration is required, and therefore the ability to logon is needed, if using the Q&A gate.

    Yes, it is true that no actual logon is being made, hence not needing the trust. However, I would not be surprised if the trust would still be needed.

    Really interested in hearing the results from David

    Jorge de Almeida Pinto [MVP-DS] | Principal Consultant | BLOG: http://jorgequestforknowledge.wordpress.com/

    Monday, October 7, 2013 12:44 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    Hi All,

    Has been a while on this topic.
    I've been able to set the necessary things up: I've got two AD MA's, one trusted where the same FIM server is member off, another AD 2012, non trusted at all.

    I've tested SSPR with the account from the first, trusted AD => Works properly.

    I've tested SSPR with the account from the untrusted forest => error

    Unable to resolve identity using NTAccount Object. System.Security.Principal.IdentityNotMappedException: Some or all identity references could not be translated.

    I've been following the steps from Kent Nordström see http://konab.com/automate-sspr-registration-fim-2010-r2/ and using the powershell workflow Activity from Codeplex, because I can not use the SSPR registration for these users (as it can not validate their userid/password). All is working properly.

    So I've got this testuser, automatically SSPR registered (AuthN Workflow registered), with accountname, with Domain, with Domain Configuration, with email, with Login Gate Registration IDs, ObjectSID and with One-Time Password Email Address and I'm using the password reset with netbiosdomain\userid format, which results in the error.

    I've been looking all over the place for a missing thing, any suggestions?
    Looks like I need to register the domain netbios name somewhere?

    Kind regards,
    David


    Monday, February 24, 2014 12:27 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi David,

    I am not quite sure what you try to achive at the end but I wll answer the questions I understand:

    Yes, FIM can Set Passwords in untrusted Domains. The only requirement is that the Management Agent Account has permissions.

    Yes, FIM is able to send mails to recipients created in the Portal. The only requirement is the mail address must be available.

    To enable users to request new OTP without beeing able to logon is a bit more complex. I think you have to create a solution that modifies a user object in question and this again triggers a mail workflow. But because the users are not able to authenticate and logon at the FIM Portal, only by sending an email tends to be misused.

    Cheers, Henry

    Monday, February 24, 2014 1:03 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    Hello Dave

    you cannot allow users for Password Reset in your Environment without having a trust. It is not sufficent having their Domain Name, Account Name  and SID. They have to logon. But they can't without trust.

    Here you will find a solution using UAG/ADFS and shadow accounts. (I know, it is a bit outdated) but it will work.

    https://blogs.technet.com/b/identityjunkie/archive/2011/05/19/federating-fim-2010-using-uag-adfs-and-kcd.aspx

    Henry

    Monday, February 24, 2014 2:46 PM
  • Question
    Sign in to vote
    1
    Sign in to vote
    The error message suggests that FIM is using types from the .NET base class library to translate "DOMAIN\username" to a SID, e.g., using 'new NTAccount("DOMAIN\\user").Translate(typeof(SecurityIdentifier))' in C#-ese.  I'm skeptical that this bit can be made to work without a trust.

    Steve Kradel, Zetetic LLC

    Monday, February 24, 2014 3:37 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    Hi All,

    I'm pretty close... I do have the errors in the FIM event log (eventid 3), but It does send the mail out to the recipient. It looks indeed that the search is somwhere via the directory services interface (.Net).
    I'm doing some additional testing at the moment, I'll let you all know.

    @Henry, yes I'm doing that via Workflow (see link) and yes it tends to be misused, but this is how it's functionally requested by the business. This might evolve in customizing the SSPReset pages with a captcha. Additionally, the users will use their email address instead of an account, so that's my next challenge :)    

       - I think I'll have to blog on all the steps and details when I'm rounding up ;)

    Kind regards,
    David

    Monday, February 24, 2014 7:39 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    Hi All,

    I'm now this far: 
    PWReset Activity's MIIS Password Set call failed with call-failure:0x800706FB
    (eventid 3 in source Microsoft.ResourceManager).
    I've searched the internet for this, no postive results.

    my email is working, my code entering is OK, but after entering the password, my AD Management Agent towards the "untrusted" AD seems to throw this error.

    My untrusted AD MA:

    • is configured running under the Built-in Domain Administrator 
    • is configured NOT to run in separate memory space (doesn't work otherwise)
    • the extension is set to "Require secure connection for password synchronization operations"
    • my target untrusted AD is able to work via LDAP SSL (tested with ldp.exe)
    • The CA certificate is trusted on my FIM server and the untrusted AD.
    • I've tested the password directly on the untrusted AD to see that it's not a password policy error
    • I've enabled (security) auditing on the untrusted AD, I do see successful logons of the user

    Ideas are welcome :)

    I'm doubting if this is actually using the LDAP + SSL + unicodepwd option to get this set password done, and this is actually using RPC

    Kind regards,
    David

    Thursday, February 27, 2014 6:02 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    This is becoming a blog, but I want to share my different steps in this quest.

    Error 0x800706FB means: ERROR_NO_TRUST_SAM_ACCOUNT

    That is very clear, no trust, no action :(
    I've created a trust between the two forests (non transitive), and this change makes the password reset to work properly, as stated by some of you in this thread, and proves that my config is OK (except on the requirement of a trust). 

    We're now thinking of using the PowerShell MA to get this solved, as a trust is not acceptable from design and business requirements. In this we will not use the ADSI but the native LDAP way to get the password updated (http://support.microsoft.com/kb/269190).

    The dev team should really think of extending FIM in capabilities:

    • allowing FIM SSPReset towards non trusted ADs (no NTaccount.translate which is not needed + these errors can be ignored as the workflow continues)
    • allowing password management in the AD MA to a non trusted AD
             (by example using LDAP + SSL + unicodepwd instead of ADSI)

    Kind regards,
    David

    Friday, February 28, 2014 3:11 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi David,

    I have to do the same activity can u please provide me the steps or any document  so that i can do the same.

    Thanks,

    Aman  

    Monday, April 28, 2014 2:43 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Aman,

    You can't do it without trust for the AD MA.

    That's the whole point of my testing here. I've created a trust, everything works properly now.

    Kind regards,
    David.

    Tuesday, September 16, 2014 3:49 PM