My institute currently has a local domain running on Windows Server, like a lot of business networks. I would like to build a web app that users can log into using their Windows login credentials, so that they don't have to manage multiple usernames and passwords.
Is this possible?
The app would be built with node.js and designed so that it could launch on mobile devices that are not on the network.
Also, I'm a student so please forgive my overwhelming ignorance on the matter. :)
Related
we are running a trading B2B platform were we cannot create testing accounts on a production environment.
Currently we are trying to submit an app to the Microsoft teams catalog, the submission process asks for test credentials to be used to test the app and the connection to the platform alongside the manifest file. however we can only provide sandbox test accounts, which will obviously cannot be used in the production app, and are hosted under different links.
in the manifest to be submitted we setup the production links for the app that needs to be submitted to the store.
The question here is how is this usually handled? how should we provide a sandbox test accounts and a production manifest at the same time for the app submission process?
Basically what Microsoft is asking for is credentials to a test Microsoft 365 tenant, where they can log in and install your app. Your app must for sure already be 100% "production" ready - live hosting etc., not a test setup behind the scenes.
We have an application which is hosted on the on-premises Windows server (IIS) server
now I created a windows server on azure and building a web app for it.where the application needs to authenticate the user by windows server (DC) using kerbrose protocol but I couldn't find any documentation regarding this from Microsoft's side
Is the above query possible to be implemented in the azure web app?
No, it's not possible. Windows Authentication is something for on-premise deployments. For Azure Web Sites Azure Active Directory is clearly the best option. Sync from AD to Azure Active Directory is also quite easy to setup.
If you still want to absolutely use Windows Auth and host your website on Azure, you can create Windows VM and host your website there. You then need to join the VM to your AD. To this, both VMs must be in the same network. So if your VM is on-premise you will need to create an site-to-site VPN.
For more information, follow this SO which also discussed about this.
If your intention is to join the VM hosting the website to a domain then as others have mentioned, this isn't possible.
However, doing Kerberos authentication itself within an Azure website isn't particularly difficult, but it does require manual implementation. Windows natively handles all of this for you on domain joined machines and and IIS exposes that functionality. Since you can't domain join you have to manually do all that heavy lifting and request and validate the tickets yourself.
This involves creating a service account in Active Directory and keeping the account password in sync. Once you have that you need to indicate to the browser that it needs to negotiate auth, which is done with the WWW-Authenticate: negotiate header on a 401 response. The client, if configured to send tickets, will send a ticket in the Authorization: Negotiate YII... request header on a subsequent response. At this point you need to shove that negotiate header and that original service account password into something that can validate Kerberos tickets. Windows SSPI will do this for you, but it's a pain. I built a library that'll do this for you: Kerberos.NET. YMMV with what works best for you.
All of that said, it may be more beneficial to switch over to a more modern authentication mechanism like OAuth/OpenIDConnect/SAML.
There are several ways depending on if you have to allow access to users who are associated with a on-premise Active Directory or not.
You should have a look at this service: https://learn.microsoft.com/en-us/azure/active-directory-domain-services/
It will offer an Active Directory within Azure where you can domain join your VM to and then using Kerberos as authentication protocol (should work the same way like on prem).
The other option would be to create a new Active Directory within your Virtual Network (via 1 or 2 small Windows Server VMs where you create the AD).
The good thing if you are using Active Directory Domain Services would be that you could extend it to your on-prem Active Directory by synchronizing or federating your on-prem AD.
There are more informations regarding these scenarios here:
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-hybrid-identity
For a Azure App Service - Web App you would connect it to your Azure Active Directory (AAD) and use the hybrid identity model to allow users who originate from an on-prem AD access to it:
https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad
Hope this helps a bit, it is a rather complicated topic you are digging into.
I have been trying to make my application verified for quite some time already. The main problem that I have is that my homepage and other pages(except web hooks for push-notifications and oauth2 flow) are private (because it's dev environment, not prod) and if you try to access them from the Internet, firewall will not allow you doing so.
Considering what I wrote above, I posted OAuth Developer Verification Form with the links to my app that aren't accessible for the external network. Now I got the following message from Google:
Dear Developer,
Thank you for your patience. Please reply back with a test account email and password, so we can experience the user sign-up flow, validate the app services and then proceed with OAuth Verification process.
Please do not hesitate to reach out to us if you have questions or concerns.
Even if I provide the account in my application, Google will not be able to reach the application.
I am sure that there are thousands of applications that have DEV/QA and other environments that aren't accessible from the Internet.
How do you go through verification process?
How do you go through the process in general?
What URLs do you specify in the form? Are they private?
How do you provide user for the Google if you application is not available through the Internet(only web-hooks are available)?
This was so easy for PROD environment, but appears a real nightmare for DEV environments.
Thank you!
I'm about to finish an app that will run on Windows Phone and Android. It uses an azure web API and push notification service.
I was wondering if there is any standard or recommended way of protecting the 'signup' or 'register' functionality within an app like this? I note that some popular apps like snapchat will send you a text to verify the registration process. That would be ideal but obviously seems unfeasible for a modest app such as mine :-)
Can anyone enlighten me to some common ways to protect the 'register' functionality of a mobile app?
Thanks for any help!
Azure provides feature sets like Azure Mobile Services that provide authentication features that you can use in your Windows Phone apps. I doubt the authentication Azure Mobile Services uses is restricted to just Azure Mobile Services, but more information on getting started with this authentication can be found here:
http://azure.microsoft.com/en-us/develop/mobile/resources-wp8/#header-2
How are people handling the distribution for Enterprise apps on WP7?
I have an app that is real basic and only has some static info, but I don't want to put it in the Public Market with the Hidden option enabled because that doesn't seem secure enough. It seems like if there was a way to verify that the user has a company email account setup on the phone on startup that would unlock the app, but I dont think thats possible.
There's currently no features in assisting for enterprise apps. You'll have to verify the authenticity of the user in your application, by requesting credentials, or requiring the application to be on a company network (or visa versa).
As for distribution, hidden publication is the only real option you have, as beta-distribution is limited to a few accounts.