Forum Widgets
Latest Discussions
CSP Partner Licensing Question - Dynamics / CRM Online Portal Additional Portal
Recently I was asked to locate a part number for the Dynamics 365 Enterprise Edition - Addnl Portal(QO) in the perpetual and NCE CSP price lists, but cannot find it. The PowerShell returned that they are being billed for a CRM_ONLINE_PORTAL1d4e9cb1-708d-449c-9f71-943aa8ed1d6a. I believe the part number is a legacy sku that was moved to Dynamics 365 Portals, but then deprecated or moved to Power Pages, but the client is still getting billed and uses it. Any guidance/ assistance would be appreciated.Licensing around CRM Online/ Dynamics Portals/ Power Pages
Recently I was asked to locate a part number for the Dynamics 365 Enterprise Edition - Addnl Portal(QO) in the perpetual and NCE CSP price lists, but cannot find it. The PowerShell returned that they are being billed for a CRM_ONLINE_PORTAL1d4e9cb1-708d-449c-9f71-943aa8ed1d6a. I believe the part number is a legacy sku that was moved to Dynamics 365 Portals, but then deprecated or moved to Power Pages, but the client is still getting billed and uses it. Any guidance/ assistance would be appreciated.PSA: Verified Publisher (Wrong) Assumptions
First and foremost, thank you, Nilesh Vishwakarma and Deepack, for sharing your internal knowledge to dispel the unnecessarily confusing topic of App Verified Publisher. I'll dive into the details of the issues, the confusion, and what I gathered during a few meetings with Microsoft Support. But first, for those seeking the simple TLDR guidance (specifically for the Verified MPN): The organization/tenant the App is under must have its own Partner Account; you can't come in with your own MPN for your clients; it needs to be their (your clients') MPN Account. Even if you created the App (the App Owner), you need some sort of Global Admin type access, and it seems like you also need some access in the associated MPN account. VERY IMPORTANT: Even if you can see and click on the Verified Publisher link to add an MPN ID, any errors you encounter are likely due to lacking rights in one or both systems. VERY IMPORTANT: The Microsoft documentation for troubleshooting this issue may lead you astray. After several days of troubleshooting on my own—reading, researching, and even involving Microsoft Support—the issue was finally resolved when my client created an MPN account, logged into Entra, clicked the Verify link, and entered their MPN ID. The takeaway here? Assume you're at the mercy of the zero trust hammer, and for something as simple as single sign-on authentication, your clients must become Microsoft Partners. For those not interested in the juicy details or listening to a grumpy gray beard rant, you are hereby released; the above are the main points to remember when applying a Verified Publisher to your App. For the rest of you, read on, and hopefully, you'll pick up more details and maybe even find it entertaining... First, if you are creating a simple App for SSO (work/school) for use on your client's website, you need to create the App on the tenant that holds the AD/Entra accounts. This makes sense. Furthermore, a publisher is required to be on the hook for and prove the validity of the App, visible to users during the consent. This also makes sense. However, what doesn't make sense is that the App Owner cannot assign the MPN ID, and even more so, anyone who is creating that App for their client needs also to have access to their client's MPN Account, and, for that matter, that the client should even need that MPN Account. Let's start with an extreme example... I'm building a website for a construction company that doesn't have an IT team. Because they have AD/Entra and I'm a loyal "Microsoft Partner" (see what I did there), we decided to go with Azure and Entra. First, I need to explain the access I think I need to the client (who is not technical). I'm on my way, creating the App and website, and I get to this Verified Publisher thing. Okay, no problem... I can click on this link to add my MPN ID. Nope, that's the first error. After finally figuring out that they need to become a Microsoft Partner, you help walk your (again, non-technical) client through this process. Okay, so you are back at the Verified Publisher with your (ahem, I mean their) new MPN ID. Again, you click on the link and add their MPN ID, and another error occurs: "The MPN ID you provided does not exist, or you do not have access to it. Please provide a valid MPN ID and try again." Okay, first, the MPN ID is valid; second, it exists; and third, what access do I need? This kitchen sink error message is not very helpful. But hey, there's a "learn more" link. Okay, so you go through hours of rummaging through the docs, and nothing is really apparent, but look at this—there's a Troubleshooting section. On the first bullet point, step four provides a link to verify the MPN (https://partner.microsoft.com/en-us/pcv/accountsettings/connectedpartnerprofile), but this reveals a "Sorry, something went wrong. Please try again later" error page. With humility, you create one of your two allowed support tickets... and when going through the same steps, they mention something about access and start naming the people that could apply the Verified Publisher... so, we have to call our (non-technical) client again to come on the chat to be walked through how to add the MPN ID, and boom, it works. At this point, you're probably part happy, part embarrassed (for no reason), and part angry. Here's the problem—well, one of them. If you don't have access to do something, we are all trained to see disabled buttons/links; if the developers are really good, they change the CSS/cursor on hover, and if they're really, really good, they provide a tooltip explaining the access that is needed to click the button or link. BUT, for all that is good, don't provide a clickable link, a non-disabled textbox, and a non-disabled button to add something we can't add in the first place. Furthermore, do not provide an overly elaborate yet somehow vague validation message. I expect more from Microsoft. Secondly—and this is a self-preservation thing—requiring our clients also to become Microsoft Partners dilutes the value of being a Microsoft Partner. I see a cartoon of a word bubble above a technical person saying, "I'm a Microsoft Partner," and in the next frame, it shows a roofer, a janitor, a homemaker, and a plethora of a thousand people, all with the same word bubble saying, "Yeah, so are we!!!" Although this is a funny view of it, the reality is that it was hard enough to explain to clients why you want to add your MPN ID to their Azure subscription or what that means... but now, why would they, when they have that same feeling of ownership as with the App, and now armed with their own MPN ID? It truly is diluting the value of a Microsoft Partnership and, further, making it harder to justify adding our MPN ID to signal to MS who we are serving. This is directly tied to how we can obtain a Silver or Gold Partnership. This seems to have been built without consideration for agencies, small businesses, and clients outside the tech field.
Purchase OR Sign In Authentication of MS 365 Subscription
We are a software provider that offers completely secure and private Remote Desktop solutions to consumer and business customers. What is the authentication process for a customer that uses our software to access their desktop remotely AND either purchases a Microsoft 365 subscription while within our software (servers)?
I can't get the sales report via API
Hello! I want to get a sales report using the API. I do everything as specified in the documentation at this link https://learn.microsoft.com/en-us/windows/uwp/monetize/acquisitions-data I receive the access token successfully, but when I try to get the report I get the error {"data":null,"errors":[{"code":"Unauthorized","message":"Authentication Exception.","trackingId":"320799ce-627c-47ba-95f7-af752af454e9"}],"statusCode":0}REPOST from Old community | OAuth Refresh token has expired after 90 days
PROBLEM: We have encountered an issue on our live environment: The Multi Factor Authentication does not work anymore. We try to authenticate using an OAuth Refresh Token (this authentication mechanism has been recommended by the Yammer group "Partner Center Security Guidance", which now has been closed). But since today, this authentication does not work anymore, but we get the following error message: invalid_grant: AADSTS700082: The refresh token has expired due to inactivity.The token was issued on 2019-01-02T09:19:53.5422744Z and was inactive for 90.00:00:00.: But I am absolutely sure that this refresh token has been successfully used yesterday. The Microsoft documentationhttps://docs.microsoft.com/en-us/graph/auth-overviewsays that an OAuth Refresh token should only expired if it has been inactive for 90 days. But our tokens were used. Therefore the tokens should not expire! Why do we now have a live incident? What went wrong? Please not that we are selling in 12 different markets, and therefore have 12 different partner accounts, and therefore 24 different OAuth refresh tokens (one for the live environment and one for the sandbox). Therefore it is not this easy to update the 24 OAuth refresh tokens. What can we do to avoid similar production incidents in the future? We are regularily using the refresh tokens to get new access tokens. We do this using the call"POST /{tenant}/oauth2/token grant_type=refresh_token&refresh_token=..."(seehttps://docs.microsoft.com/en-us/azure/active-directory/develop/v1-protocols-oauth-code). The response of this call not only contains the access token, but also a new refresh token. At the moment, we ignore the new refresh token that is returned. Should we store and use the new refresh token that is returned by this call, or would the new refresh token also expire at the same time? Does Microsoft offer a way to find out the expiry time or the issued-at-date of a refresh token? RESPONSE TO USER: Please check that you store your token(cache) also after AquireTokenSilent. You will get a new refresh token which you schould use in sequential requests. In my case I did not (correctly) store it, so I used the refresh token which I aquired the first time when I used AquireTokenInteractive. That token will expire after 90 days. There are two authentication flows: a confidentialclient which authenticates the application. The application has access to the resources of your organisation, but you have little control over who uses the software. This is, even for background processes, not workable when you develop your own software for multiple customers (you cannot guarantee that customer 1 might never access data from customer 2). In that case you develop a Public Client where you get access via a user's account via AquireTokenInteractive (that method also supports multifactor authentication and it shows any consentscreen necessary). Once you have access you can use AquireTokenSilent to renew the token. Note that AcquireTokenSilent DOES return a refresh token (valid for 90 days), and you should make sure you store this after every request. The refreshtoken is not visible if you look in the debugger, but it is visible if you use Fiddler to view the raw data (and decode the token). That was in hindside my problem: I created a daemon process for which the interactive flow does not seem logical, and since I had token issues I went for the confidential flow. But there you do not get the consent screens and it does not work with multifactor authentication. My conclusion: if you are developing 3rd party software then even for background (daemon) processes you could (should) use the publicclient flow. There is no problem with the token process: it will continue to work forever once you aquire a token. Only when your software is 'down' for more than 90 days you will need to log in again (and when access for your app is changed from the client's azure account) Relevant links: https://docs.microsoft.com/nl-nl/azure/active-directory/develop/msal-client-applications https://docs.microsoft.com/nl-nl/azure/active-directory/develop/msal-net-acquire-token-silentlyRepost: Logging for failed events shows "an account failed to log on" but for a server
Question: We have recently turned on security event loggging and see failed logon events for the servers name. How do we resolve this? Subject: Security ID: S-1-5-20 Account Name: DC-SERVERNAME-1$ Account Domain: DOMAIN NAME Logon ID: 0x3E4 Logon Type: 5 Account For Which Logon Failed: Security ID: S-1-0-0 Account Name: - Account Domain: - Failure Information: Failure Reason: An Error occured during Logon. Status: 0xC0000022 Sub Status: 0xC0000022 Process Information: Caller Process ID: 0x4fc Caller Process Name: C:\Windows\System32\svchost.exe Network Information: Workstation Name: - Source Network Address: - Source Port: - Detailed Authentication Information: Logon Process: Advapi Authentication Package: Negotiate Transited Services: - Package Name (NTLM only): - Key Length: 0 This event is generated when a logon request fails. It is generated on the computer where access was attempted. The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe. The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network). The Process Information fields indicate which account and process on the system requested the logon. The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases. The authentication information fields provide detailed information about this specific logon request. - Transited services indicate which intermediate services have participated in this logon request. - Package name indicates which sub-protocol was used among the NTLM protocols. - Key length indicates the length of the generated session key. This will be 0 if no session key was requested." within the policy "Failed Logon Attempts". The Virtual Machine (Microsoft Corporation) was last accessed by "null" on 2019-10-21 02:22:57.0 Response: Logon Type: 5 Looks to be a problematic service startup or logon https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4625
