none
MIM 2016 portal - Unable to log in RRS feed

  • Question

  • Hi.

    I'm doing my first real installation of MIM 2016, mostly following the steps in the MIM 2016 handbook. My big problem is that I'm a complete noob when it comes down to Sharepoint, never worked with that before. In the MIM 2016 course all the Sharepoint stuff was already fixed in the lab machines...

    Anyway, the problem I'm having now is that when I try to access the portal I get this error:

    Error processing your request: The server was unwilling to perform the requested operation.
    Reason:
    The requester of this operation is invalid.
    Attributes:
    Correlation Id:
    321ba8a4-d447-4720-be73-c82736d177db
    Request Id:
    Details:

    The requestor’s identity was not found.

    When googling for the problem most solutions seem to refer to stuff that I need to fix in the portal, which seems like kinda catch 22 since I'm unable to log in to the portal.

    The account I'm using is configured as secondary site collection administrator.

    Application log says nothing useful. Sharepoint log says a whole lot but I'm not really sure what is relevant and not...

    Thursday, March 2, 2017 9:55 AM

Answers

  • Found the error. For some unknown reason "ASP.NET Impersonation" was inaktivated for that site in IIS. No idea why and no idea what difference it makes, but now my portal suddenly works like a charm :-)
    Monday, March 13, 2017 6:16 PM

All replies

  • The account should be in the portal too. And in the portal the account should have accountname, object sid and domain information. After that you need to enable 2 mpr's:

    • “General: Users can read non-administrative configuration resources”
    • “User management: Users can read attributes of their own”


    So that error message is not related to sharepoint.

    • Proposed as answer by 2xTsei Thursday, March 2, 2017 10:21 AM
    Thursday, March 2, 2017 10:21 AM
  • The account IS in the portal with the right domain, accountname and objectSID (I've been able to determine as much using Export-FIMConfig in Powershell).

    I've discovered now though that it's not me it's trying to log in. In the Forefront Identity Manager log I get the following:

    GetCurrentUserFromSecurityIdentifier: No such user <domain>\svcMIMSPPool, S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxxx

    I get the above every time I'm logging in and the account in that message is NOT the account I'm using for logging in, it's the account that owns the application pool in IIS (and that account does NOT exist in MMIM). Why the heck would it try to log in that account into MIM?

    Hmmm... This has got to do with the useAppPoolCredentials, right? According to the handbook useAppPoolCredentials should be set to true for the MIM Portal site, it sure sounds like that would use the app pool credentials instead of mine which is exactly what I'm seeing. I've tried now turning it to false though and it makes no difference. Am I on the right track here?
    Monday, March 6, 2017 1:45 PM
  • Ok, this is officially driving me completely mad now. It's obviously something I still don't understand here after reading every page on the web that seems related.

    I've now been trying back and forth with authenticationmethods for the sp webapplication (using Set-SPWebApplication -authenticationmethod). Obviously it should be Kerberos, but what I found out was that when I change to NTLM and back to Kerberos I get the problem that I describe in the OP. However that seems to be because when I do that, requireKerberos is removed from the resourceManagementClient in the web.config, which I guess means it doesn't use Kerberos at all?

    Problem is when i add requireKerberos back there I got another problem: When I'm trying to load the site it returns nothing. No errors anywhere, it just loads forever and gives me nothing at all. And according to klist there are no cached tickets, so it seems it doesn't try using Kerberos anyway. Trying from a non domain computer it asks me for credentials though.

    I guess if no guru here tells me what I'm doing wrong I'll have to tear the entire environment down and start from scratch. I thought this was the easy part, haven't even started doing the "real" job wih identity management yet...

    edit: One thing I found is the following rows in IIS log:

    2017-03-07 09:45:40 172.25.0.159 GET /identitymanagement/default.aspx - 80 - 172.16.2.62 Mozilla/5.0+(Windows+NT+10.0;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - 401 2 5 0
    2017-03-07 09:45:51 172.25.0.159 GET /identitymanagement/default.aspx - 80 - 172.16.2.62 Mozilla/5.0+(Windows+NT+10.0;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - 401 1 2148074254 0

    They happen every time I try to access the MIM Portal. The first row makes perfectly sense to me, it asks for authentication. But then??? Googling 2148074254 gives me hits about spn problems, but I'm quite sure I have control over spn (both http/mimportal and the corresponding fqdn entry points to svcmimsppool, which is the account that runs the pool).

    Tuesday, March 7, 2017 9:12 AM
  • what is the MIM handbook you are referring to? Could you please give me a link?
    Tuesday, March 7, 2017 10:34 PM
  • https://www.packtpub.com/virtualization-and-cloud/microsoft-identity-manager-2016-handbook

    By the way, the problems I described in my last post turned out to be not relevant (when changing back and forth between Kerberos and NTLM it automatically removes "requireKerberos" from web.config and that obviously lead to other problems). So I'm now back to square one, it tries to log me into MIM using the account that runs the app pool instead of the account that I actually use.

    Wednesday, March 8, 2017 6:46 AM
  • Do you have any account which can connect to the portal? Also is the installation account able to connect to the portal?

    And post the script what you have used to check that everyrting is ok with the account you are currently using and the results too!

    Wednesday, March 8, 2017 9:37 AM
  • Do you have any account which can connect to the portal? Also is the installation account able to connect to the portal?

    And post the script what you have used to check that everyrting is ok with the account you are currently using and the results too!

    The account I'm trying to log in using IS the installation account, that's the only account that currently exists in my MIM service. So no, I have no account that's able to log in.

    I haven't used any special script to check the account (didn't even know there existed specific scripts for that). It's a normal domain account (in fact it's a domain admin account).

    Wednesday, March 8, 2017 3:13 PM

  • The account I'm trying to log in using IS the installation account, that's the only account that currently exists in my MIM service. So no, I have no account that's able to log in.

    I haven't used any special script to check the account (didn't even know there existed specific scripts for that). It's a normal domain account (in fact it's a domain admin account).

    If you can run Export-FIMConfig, your account should be OK. Export-FIMConfig requires working credentials. So the problem is with your sp/iis config. I know that doesn't help much, but at least it should narrow it down somewhat.


    FIM architect - Crayon AS - www.crayon.com

    Monday, March 13, 2017 8:02 AM
  • If you can run Export-FIMConfig, your account should be OK. Export-FIMConfig requires working credentials. So the problem is with your sp/iis config. I know that doesn't help much, but at least it should narrow it down somewhat.
    Yep, good point. I've been suspecting sp/iis the whole time though (and put my efforts there) without any success... I've hooked up with a MIM guru now though that is gonna connect to my environment later today and hopefully he'll find the problem. I'll report back later and tell you how it went :-)
    Monday, March 13, 2017 8:16 AM
  • Found the error. For some unknown reason "ASP.NET Impersonation" was inaktivated for that site in IIS. No idea why and no idea what difference it makes, but now my portal suddenly works like a charm :-)
    Monday, March 13, 2017 6:16 PM