Can I upload a custom app in my teams for tenant "A"(I have the upload custom app link enabled by teams admin) which is not published to the Teams App store yet.
The custom app contains a bot registered with Microsoft bot framework and does not contain tabs.
The Microsoft App Registration for this app is registered in other tenant "B" and the app doesn't require any special delegated or application permissions to Microsoft graph
Yes this should work no problem. Depending on what you app includes (Bot, Tab, etc.) these should work fine, provided:
the user's device can access the system no problem (e.g. if your tab is hosted on a public httpS url, versus let's say an internal-only address that only people in tenant "A" could access
you don't have any tenant-specific filtering on (for instance, there are bot samples that show how to -restrict- your bot to only users from a specific tenant). This is NOT the default though, you would have put this into your bot specifically. By default it will work fine across tenants.
Related
In the organization where I am trying to deploy a chatbot in MS Teams, because of security posture and separation of responsibilities, the MS Teams' admin team (different from bot developers), cannot create a new Azure AD app when creating a bot in App Studio. The authorization to create Azure AD app is only with AAD team.
To work with this process, we requested and got an application created in AAD via AAD Team. After creation of AAD app, the AAD team also gave us application name, application id and object id ;
Now, the MS Teams' admin team is asking for process/documentation to link chatbot to be created in app studio to AAD app. Can someone share these instructions or point to any existing ones ? (I couldn't find any in my searches).
The short answer is that this needs to go into the "botId" section in the Teams app manifest (see here for refence: https://learn.microsoft.com/en-us/microsoftteams/platform/resources/schema/manifest-schema). Longer answers:
You might not be editing a manifest directly - you are doing it in App Studio, so just go to the Bot section and that's where you capture the Bot ID
It sounds like there is a missing piece in what you are trying to do. You need:
a. an Azure Application (got)
b. a Teams app where you can capture the Azure App ID as bot id (got)
c. a 'Bot' registration in Azure (it's a kind of Azure resource) - have you got this already? If not, someone with Azure access will need to create it.
There is a section in the wizard to use an existing Azure Application - you'd need to select that and enter the Azure application id.
Here's more info on doing the bot registration: https://learn.microsoft.com/en-us/azure/bot-service/abs-quickstart?view=azure-bot-service-4.0&tabs=userassigned. For the screenshot in section 6, I recommend choosing "Multi-tenant" as the app type (then you can skip the 'Bot identity information' section later), and for 'Creation Type' is where you want to link to the already-created Azure Application.
Also note the "pricing tier" - by default it's on "standard", but you can change to the "free" tier to see if that's sufficient for you - your bot needs to be handling a lot of message to need to move up to the paid tier.
What I did end up doing was:
Create an app registration in azure with a secret. The secret becomes bot password in teams.
Create a bot using https://dev.botframework.com/bots. Since my app/bot is single tenant, I needed to be able to create a bot without azure service which requires subscription. I enabled Teams for this bot, besides web chat which is enabled by default.
Create an app using app studio, referencing the azure app and bot from botframework.
I have a WPF desktop app which connects to an Azure registered app. Within that registered app I have created App roles. Then, within an Azure Enterprise App, I add a user with one of the app roles created in the app registration. However, I can't figure out how to use this app role. I can't seem to access the role from the JWT token returned during authentication nor can I seem to use the role to modify access in Azure.
How can I use the app role to modify access?
Firstly, your WPF app doesn't call any APIs (official API or you own Web API) based on your description.
And you define the app role in the app registration which represents your WPF app. We can call it client-side app although there is no service-side app here.
So in this case, the app role should exist in the id token (not access token).
You need to parse the id token in your code and find the app roles and then verify them.
There is another situation where you are actually calling some kind of API, but you did not mention it in the post.
In this case I think you want to get and verify the app role from access token. We need to define the app role in the app registration which represents the service-side app.
There again are two situations.
One is that you are calling an official API, such as the Microsoft Graph API. This situation will not allow you to set the app role on the service side because we do not have the permission to change the official Microsoft Graph app registration. You need to take advantage of app roles from id token as introduced above. But usually we don't control the permissions like this because Microsoft Graph has its own permission control method.
The second is that you are calling your own Web API hosted on Azure. We call it AAD protected Web API. In this case you need to create an app registration which represents your Web API by following Protected web API: App registration and define the app role in this app registration and assign the app role in enterprise application which is associated with this app registration.
After that you can get the app roles in access token and verify them by following Protected web API: Verify scopes and app roles.
Although I have explained all these situations, this may not solve your issue.
It looks like your situation is the first one. You can first decode your id token in https://jwt.ms to determine whether app roles exist.
I have a multi-tenant (i.e. any O365 tenant) app registered in the AAD V2 app registration portal.
After registering the app I have changed the primary custom domain in the corresponding aad.
In the admin consent screen the wrong custom domain is displayed.
In the manifest it also shows the incorrect publisherDomain. The publisherDomain setting cannot be changed by editing the manifest.
The app name, logo, terms link, privacy link can all be changed as expected.
If I register a new test app the publisherDomain in the manifest is correct.
The app is in production with several clients using it. I don't want to have to delete and recreate the app registration to resolve this.
After registering the app I have changed the primary custom domain in
the corresponding aad.
When you register an application using https://apps.dev.microsoft.com/, the application will be registered in the home tenant of the account that you use to sign into the portal. If you explicitly wish to register an application in a particular tenant, sign in with an account originally created in that tenant.
After the app registered, property publisherDomain is read-only and cannot be set.
I created a "Web app / API" app in our organization's "xxx.onmicrosoft.com" Azure Active Directory. The app's "Multi-tenanted" property has been set to "Yes".
We configured OpenID Connect (we use https://github.com/mitreid-connect/) to use the following URLs:
https://login.microsoftonline.com/common/oauth2/authorize
https://login.microsoftonline.com/common/oauth2/token
Please note that we used "common" in the URLs and we didn't use "xxx.onmicrosoft.com" because we want people from outside "xxx.onmicrosoft.com" to be able to authenticate and access our app.
With those settings, the people from xxx.onmicrosoft.com can properly authenticate and access the app.
However, when I use my personal live.com account (with username xxx#gmail.com) to access the app, I get AADSTS50020 error. I am able to properly authenticate with my xxx#gmail.com account, but I do not get redirected to the Reply URL. I'm stuck on Microsoft's Web page with the following error msg:
AADSTS50020: User account 'xxx#gmail.com' from identity provider
'live.com' does not exist in tenant 'xxx.onmicrosoft.com' and cannot
access the application '391e7103-ZZZZ-zz87-xxxx-7xxxxxd5xxxx' in that
tenant. The account needs to be added as an external user in the
tenant first. Sign out and sign in again with a different Azure Active
Directory user account.
What configuration do I need to change if I want people from any identity provider to be able to access my app ?
Like it has been stated here, I expected that people from anywhere could access my app without requiring more configuration on my side.
I'm asking this question because I'm in the process of getting certified for AppSource and this currently blocks me from being able to do so.
AppSource only requires work accounts to sign-in. You are using an #gmail account - which is a personal account - and because you are using the Azure Active Directory v1 endpoint in addition to common (https://login.microsoftonline.com/common), it can't accept personal accounts to sign-in directly - only work accounts.
You have three options:
If sign-in personal accounts is not a requirement for your application, then you can continue using the v1 endpoint and use a work account to sign-in/test your application. This will make you ready for AppSource certification.
If you need/ want to allow personal accounts in your application in addition to work accounts, then you can consider using the v2 endpoint (https://login.microsoftonline.com/common/v2.0) for Azure Active Directory. The v2 endpoint allow both personal accounts and work accounts to sign-in with no effort.A note is the v2 endpoint has some limitations: if you can live with these limitations (for example, your application only needs to sign-in users and eventually make queries against Graph API), then in general it should be fine to use, but if you need extra features like protecting your own Web API with scopes, then this feature is not released at this point (as November 2017). Please read this document for an updated list of limitations of the v2 endpoint.
A third (but less recommended option for AppSource) is to keep using the v1 endpoint and make your application to be single tenant - which is to change the endpoint from https://login.microsoftonline.com/common to https://login.microsoftonline.com/{yourtenantid}, and then use B2B invitations API to invite every external users (including work and personal accounts) to be part of your Azure AD tenant/organization. More information about B2B here as well.
The option '3' above have some consequences for management as well for AppSource: by using this option, you are required to have one Azure Active Directory tenant (if you don't have a tenant already, you can get one using these instructions), and the users being invited will be guests accounts of this tenant - this mean that you need to invite every external user to your application/ tenant. A multi-tenant application allows any user from any organization to sign-in to your application with less management on your side. In general for SaaS applications, multi-tenant configuration is recommended.
For AppSource, also the option '3' leads to a less-immersive user experience (Partner led trial), where the end user won't be able to access your application's demo right away - mainly because that they have to wait for the invitation's email and accept it (user has to accept being guest of your tenant) so that they can access your application.
For more information about AppSource requirements and trial options - please see this article.
I am developing a multi-tenant Office 365 daemon that requires access to user calendars.
I have successfully registered in the company tenant (Tenant1) that has deployed this app using certificates and I am able to get access tokens.
Now I created a separate AAD tenant (Tenant 2) and logged in to daemon app using administrator account of Tenant 2, it prompted the Admin Consent screen and I provided consent. There was no errors returned.
When I tried to get an app token however, I am able to get a token but with blank permissions. If I call the Office 365 API using this token, I get a 401.
I was of the view that service principal objects should be created. Also I am unable to see this app in Tenant 2 app registrations.
Do all my consumers have to register this app manually in their AD tenant and modify application manifest file to add certificate details?
I am not sure about the benefit of multi tenancy if that's the case.
I found the follow in the Azure Active Directory documentation:
The following diagram illustrates the relationship between an application's application object and corresponding service principal objects, in the context of a sample multi-tenant application called HR app. There are three Azure AD tenants in this scenario:
Adatum - the tenant used by the company that developed the HR app
Contoso - the tenant used by the Contoso organization, which is a consumer of the HR app
Fabrikam - the tenant used by the Fabrikam organization, which also consumes the HR app
You do not need to have each tenant register your application. In fact, you shouldn't since having dozens (or hundreds) of unique App IDs floating around would only create headaches for you.
Each tenant does however need to execute the Admin Consent workflow. This will authorize the App ID you've registered on your end to access the scopes you've requested.
Generally, I recommend using the v2 Endpoint and the apps.dev.microsoft.com portal for registering your app. While you can also register your app in your own Active Directory, the portal makes it a lot easier to manage.
The general process is:
Register you application in the Registration Portal
Populate the "Application Permissions" in the Microsoft Graph Permissions section.
Launch the Admin Consent workload using https://login.microsoftonline.com/common/adminconsent?client_id=[APPLICATION ID]&redirect_uri=[REDIRECT URI]
Get a beer
A couple of tips:
The Registration Portal only supports MSA (i.e. personal) accounts at the moment. I'd suggest creating a new Outlook.com account for this purpose so you can easily share the credentials with folks who need them internally.
If you create a shared Outlook.com account, you should also set up forwarding rules for all of the interested parties internally. This is in case something should every go wrong or change down the road and you need to recover the account.
I wrote a v2 Endpoint and Admin Consent primer that you might find helpful. They assume you're using the Authorization Code flow but the concepts remain the same for Client Credentials.