I have just started on LDAP and AD LDS. I know AD LDS can be used to store Application settings. But How?
Imagine I have a Factory, and under Factory I have multiple applications and all these applications need a centralized configuration management. The settings for each application would be more or less the same with little difference.
Would AD LDS be a good candidate for this?
Is there a good example on How to use AD LDS to store Application settings?
Related
I have created an app for my company. To use the application, you need to log in to the account that We ourselves create for each specific employee, registration of new accounts in the application is not available now and will not be available in the future, since only We can create new accounts for new employees and delete old accounts on our server .
Can such an application be published in the App Store, given the new requirements of Apple?
Is there any way to avoid this? Maybe if our application is unlisted, then it will be allowed to be published without explicitly registering new accounts?
We tried to submit our app for review and provided a demo account, but we were denied publishing due to implicit registration in the app.
As I know, you can create test account from your backend and provide this account authorisation info to the apple review team, so they can authorise and test your application
It is not the lack of user registration that is causing your app rejection.
For an App to be made available in the App Store it needs to be applicable to a broad audience. It sounds like your app is only for a very limited set of users; employees of your company.
For these types of apps you can use custom app distribution or unlisted app distribution.
Custom app distribution works well when an app needs to be made available to one or more organisations who manage their devices. (You can use it with unmanaged devices, but distribution is more complex).
In your case, it sounds like an unlisted app would be the best approach.
In both cases you still go through app review and will need to provide a demo login.
A third possible approach is to use an Enterprise developer program. Due to abuse in the past, Apple discourages these now that custom and unlisted app distribution is available. Enterprise programs are more expensive and are not granted to smaller companies.
I have a website which is currently live and uses Azure B2C to manage user authentication. The site has been so successful that I have decided to build App (IOS and Android) versions of the site using Xamarin.
My 2 questions are:
Can I use my existing Application Registration in B2C to authenticate both my MVC and Native Apps. If so is this done via the Allow Public Client Flows Radio button under the Advance Settings Section of the Authentication tab in Azure B2C? Will turning this from No to Yes impact the running of my registration for the website (as the system is live with thousand of users I am very wary of making updates to B2C Settings.
What is the best way for testing changes to Azure B2C? Is there an easy way to create dev environments that can then be flipped to live, switching out the live version with the dev environment?
Any help will be gratefully received.
J
Can I use my existing Application Registration in B2C to authenticate both my MVC and Native Apps. If so is this done via the
Allow Public Client Flows Radio button under the Advance Settings
Section of the Authentication tab in Azure B2C? Will turning this from
No to Yes impact the running of my registration for the website (as
the system is live with thousand of users I am very wary of making
updates to B2C Settings.
It's not recommended to use the same app registration in this case.
Please see the differences between public client and confidential client applications.
Confidential client applications are safe to keep application secrets while public clients not. If you use the same app registration, there is a conflict in keeping application secrets. And using the same app registration for multiple applications will make permission control more difficult.
So in this case, it's recommended to create a new app registration with Public client/native platform.
Turning Allow Public Client Flows from No to Yes doesn't mean to change it to native app type.
You could set "allowPublicClient": true, in the manifest file.
What is the best way for testing changes to Azure B2C? Is there an easy way to create dev environments that can then be flipped to live,
switching out the live version with the dev environment?
Creating a new app registration will not affect the use of your web application.
I want to develop and publish a bot for Teams, to interface with my SaaS (I already have a Slackbot that I'm porting). I'm creating a Bot Channel Registration as per this guide and came across the choice of whether to auto-generate a new App Id and password, or manually registering one (described here). I already have an Azure AD app for my SaaS that is published to the AppSource marketplace (the integration currently mainly allows logging in with your M365 account and syncing users from AD). Is it possible, and would it make sense to use the same App ID for the bot I'm developing for the same SaaS? Or is it somehow not advisable? And relatedly, can I expand my existing listing on AppSource to also contain the new bot, or should this be a separate listing?
I noticed in the documentation for manual registration of a bot, that it says that bots only work with "Accounts in any organizational directory and personal Microsoft accounts (e.g. Xbox, Outlook.com)" - my existing app only works with organization accounts, not personal accounts (since it's a B2B app) - does that change things?
Perhaps consider the question the other way - is there any good reason TO re-use the app ? It's very easy and basically free to create an additional app, and that way you don't run the risk of possibly ending up with settings needed for one scenario that conflict with another scenario's requirements, now or in the future. Here are some other possible considerations though:
new apps require Publisher verification, since 9 Nov 2020. This won't affect you for an internal app, which can be consented to by a global admin.
If you need the user (or admin) consent for some set of privileges (e.g. delegated Graph access), then using the same app might make sense. An example, in a Teams context, might be a bot and a tab that both need to access something from the Graph on the user's behalf. You could get consent in one context, and use it to access the resources from both contexts.
In a nutshell, and especially without a really really good idea of both of your current and planned use cases, it's hard to give a really solid 'yes' or 'no'. My gut says go with a separate app for a separate, unrelated scenario though.
Reusing the same appid against any other B2B won't create any problem. Being said that you can't use the above app if you're planning to implement/use BOT framework with it, as it's registered for organization only.
If you plan to create BOT related app registration then i would
suggest you to create new app registration with Organization +
personal for you scenario.
Please see the documentation and it's disclaimer:
In the above document it's pretty clear if you create any other app registration (other than Organization + personal), then the BOT will be unusable.
We are developing an iOS application in Xamarin, which will be distributed via MobileIron. We are also developing the Backend WebServices (rest).
What I need to know is, when a web service call comes to my API, I want to make sure, that the call is coming from a client who is logged-in to my app with his Active-Directory credentials, using MobileIron.
The MobileIron website has plenty of information, but is also a bit chaotic.
What MobileIron products are needed for my use case?
Whats the best way to protect my WebServices and allow just requests from our iOS Application with correct AD-Credentials?
Do I need the AppConnect SDK or can I just wrap the iOS Application in MobileIron? If I need the SDK, are there any examples?
Thanks in advance!
Cheers
Immi
Here is one way how it should work, we have this built up in our environment.
Assuming that the target devices are managed by the MobileIron MDM system with MobileIron Core (MDM) & MobileIron Sentry (Gateway -> Intranet).
You can configure MobileIron Sentry in this way, that a webrequest from an AppConnect enabled app (no matter if SDK included or wrapped!) will be authenticated with user certificate from device, Sentry obtains Kerberos ticket from domain controller for the user and then forwards the web request to a website / webservice where Kerberos authentication is enabled and the user has access granted.
There are many things to configure for this to work (CA, user certificate -> device, service account with delegation configured in AD, SPN for website configured in AD,...) and there is a good support document available from MobileIron to make this up & running.
It's to extensive to describe here all steps.
If this is already setup in the target environment (if there is already another AppConnect app), there are only a few steps left (SPN and MI app-specific AppConnect Config).
The good news is, that the app itself does not have to take care of the authentication. The MobileIron stuff does this on its own...
I have an app on store and all client are used it. Sometimes some client needs additional feature that isn't wanted by others so in that case I make AdHoc build for that particular client, but it is not proper solution.
I think on Enterprise solution but apple not allowed to distribute outside the organization in it and I have all users are clients.
If your app has a user login, download a user specific configfile directly after login and check in code for feature availability by looking into it. Large companies like Spotify and also startups do it this way to test new features without releasing them to all.