Orchard MultiTenancy - Where are the tenants located? - orchardcms

I'm a developer that wishes to have a landlord site which manages tenants via Orchard. I've Enabled the Orchard.MultiTenancy module, started using it and created multiple sites for my purposes.
However, I'm still somewhat in favor of coding stuff and not just edit it via a high-level Orchard user.
Trying to find each tenant's MVC site wasn't successful.
Any suggestions ?
If one tenant crashes, does it take with it all the other tenants (since I can't seem to find an Application Domain for each)?

The whole point of multi-tenancy is to increase site density by letting multiple Orchard sites live in a single IIS application. There is not one site per tenant. The tenants are only separated in the DB, but all share the same files.
If a tenant crashes, well, it depends on the crash. Most exceptions won't even take out the tenant.

Related

SharePoint: How to allow devs to promote apps when they do not have designer or owner access

I am in a SP Online environment where users do not have owner access to their sites. This makes life difficult in several areas, one of them being the promotion of apps to the app catalog. I am in a very large organization and we are looking for the cleanest way to allow devs to promote their apps to their individual sites. We also don't want to clutter the tenant app catalog.
I have been investigating site collection app catalogs. I am assuming that - once the ability for the site to have apps is enabled - that I would need to give a dev elevated access to the site in order to publish apps directly to the site?
The second question is around apps that might belong on multiple sites. If I went this route (publishing to local apps) would it then be incumbent on the devs to publish to multiple sites in their pipeline using CLI?
Thank you in advance!

Azure AD Redirect URI(s) for applications that a multi tennant

I am responsible for a web application that we sell to customers all around the world, this application is a web application that I have been tasked with including functionality to surface O365 content within, this has lead me to the MS Graph API which I am currently implementing as a proof of concept.
At the moment I have everything working within my dev environment with localhost and dev URIs listed as application redirect URIs under the AD application, however, in the real world there could be an unlimited amount of URIs that our customers are using, meaning that as I currently understand it will mean that I am going to have to either:
1) Get them to create an application within their own AD organisations or
2) Manage the URIs within in our app here locally.
Now the question I have is, what is the best approach I can take here?
Is there a secret option 3 that I have not been able to dig out from the Microsoft documentation or the internet yet?
Thank you for any help or advice you can provide.

How to enforce Azure AD authentication on IIS server level

Is there any possibility to configure IIS server to enforce Azure Active Directory authentication in hosted application? I don't want to apply any changes to app's code, it would be great to provide this authentication only on server level/layer (configuration IIS). Is this even possible?
EDIT
I have situation like this:
Have many applications from a customers. Have Azure AD and users added there. I need to provide Azure AD authentication to these applications. Moreover, i shouldn't do anything with code of these applications so i thought that i can try to enforce authentication not on application level but on server level. I've been searching informations about possibility of this method but can't find any (only application scenarios supported by Azure AD https://azure.microsoft.com/pl-pl/documentation/articles/active-directory-authentication-scenarios/ ). The only thing i have found is Azure Multi-Factor Authentication but i don't think it is helpful.
We tried to find it, and all that i have found that there is no possibility to enforce AAD authenticatoin on the IIS level and that it should be set up on the application layer which is actually the only one recommended and described process on the sites and in the AAD-related articles. I would say, that it can be even hard from a technological standpoint.
Reference 1
Reference 2

Deploying and maintaining multiple copies of the same web application at different URLs on Azure

I'm currently investigating the possibility of my company using Azure.
Our current hosting situation that we run ourselves involves a separate site in IIS for each of our clients, each one having a virtual directory to the CMS we've built with ASP.Net web forms. We can update the contents of that virtual directory, which then provides the latest version of our CMS to all our clients at once.
I'm not looking to recreate that exact situation in Azure, but I am instead interested in figuring out how to create a single Web application in Visual Studio, publish that application to Azure in such a way that multiple sites (that I've specified) are created on Azure. Then I would like to be able to make changes to that application, and publish it again in a such a way that all the sites for it get updated all together, without requiring something be done manually per site/client.
The closest explanation I've found is this one:
http://www.wadewegner.com/2011/02/running-multiple-websites-in-a-windows-azure-web-role/
That gets me close, but what I don't understand is that when I publish this application to Azure, I still only see one application / URL available in the Azure management console. Shouldn't the extra "Site" node result in a different site being available when I publish it? Why doesn't it? Is there a completely separate way to accomplish this that I'm not using?
When you look at the management console you're seeing the web roles that you have deployed, not the sites that are part of that web role which is why you're only seeing one. As long as you've followed the instructions correctly, then yes, you do have two sites running. The catch is that you can only access the main site through that default URL. Presuming you have urls that look like customer1.mysite.com and customer2.mysite.com, you need to make sure you've set these as the host headers in the sub sites and then change your DNS so both of these domains point to URL you can see in the portal (e.g. mysite.cloudapp.net).
When considering a multi-tenant solution, ideally you should design your web-application as a single website that is capable of responding to multiple tenants (each of your customers), as opposed to creating a website/web-application for each one of them. This makes updates across the system manageable.
Your web-application can partition and identity different tenants based on several options such as part of the url (e.g myapp/tenant1 vs myapp/tenant2) or via a host header (e.g. tenant1.myapp.cloudapp.net vs tenant2.myapp.cloudapp.net)
HTH

Securing SharePoint for Internal and External Users

We have both internal and external users on Windows SharePoint Services 3.0. We are using Windows Integrated authentication and have all users, both internal and external, in the same domain. We are allowing all users access to the application by adding the Domain Users group. The issue is that there are certain sites that need to be secure from the external users, but because they are in the same domain they have access. We have removed the Domain Users group from some sites and then explicitly assigned permissions to a dedicated group in Active Directory, but we have around 100 sites that we need to do this for and it would become an administrative nightmare to do this for all 100 sites.
I've done some searching and it looks like we might be able to accomplish this using zones, but when we tried last week we broke the entire application. Does anyone have any ideas?
The other option is to move the WSS server into a different domain and give the external users accounts in that domain so that we could keep them separate, but I wanted to see if there was a better way to do this.
Work on creating automation that creates and maintains Active Directory security groups that contain lists of internal or external users. Surely there is an attribute or two that distinguishes between these different types of users.
While you are at it, update your user provisioning process to make sure that when you create accounts, they get stuck in one group or another.
It would seem to be relatively simple to automate the process of changing your security using a powershell script?
An example of a script like that is here

Resources