Every guide, blog and the health analyser keeps saying that you need to set up different accounts for different services, farm account and application pool accounts.
But no-one want to explain me why! I have tried to search for an answer, and while I am pretty sure it has a good reason I just cannot seem to find one. I really would like to know why. I want to learn! Try to be concrete!
To narrow down the question a bit. What are the reason for these two security issues reported by the health analyser:
The server farm account should not be used for other services.
Accounts used by application pools or service identities are in the local machine Administrators group.
Related
I am a Solution Architect responsible for setting up a project's infrastructure on Azure. The project should be running in multiple environments (dev, staging, prod). As far as I learned the best practice regarding environment separation in Azure is to use Resource Groups. That's what I did.
However, this is where things start getting tricky. Our application will use Azure AD as OAuth Authorization Server. I want to have my AD isolated, like everything else in my infrastructure. I don't want to accidentally modify a production user from the dev environment and for the dev environment, I want to be able to create a ton of test users which I don't want to see in production. So, isolation.
The problem is I don't see any option on how to do this. My first instinct was to create multiple ADs. But when I do that, they actually need to create a completely new tenant for each of these environments. This seems really messy to me. Have to support as many (almost empty) tenants as I want to have environments.
Please, what is the right way how to do this?
Does Azure AD have some kind of support for isolation I require?
Am I missing something?
Note: this question was also asked in MS Q&A.
You're correct that a tenant is equivalent to a directory and a user is either in the directory or it's not. However, using RBAC, you can restrict the permissions on users so that they can't access particular services. It would be good if you separated permissions by subscription which is what a lot of major companies do and that's how they know which workload a subscription handles.
I really need some basic help with Azure. I purchased Microsoft 365 for my company (10 users) from GoDaddy (a mistake). GoDaddy support has little to no knowledge of Azure. With Microsoft 365, you get access to the Azure portal, and you get a directory in Azure Active Directory that looks like NETORG12345678.onmicrosoft.com. Then you can create tenants and subscriptions below that directory.
I must have done something like that, because now I am getting emails from Microsoft saying that my subscription is about to expire and I should pay the bill.
Rather embarrassing to say, but I cannot even figure out how to do this. I am the global administrator for my directory/tenant (if that is even the right terminology). I keep getting error messages that I don't have the appropriate permissions to view my bill, and I should try asking myself for permission to do that. Sometimes, the error messages say I should try switching directories, but there is only one directory, I think.
I wish there was some appropriate training for this, but I can't find anything. Sorry for the noob question.
If you are the owner/administrator you can navigate to Cost Management + Billing and see what is your subscription and the status of it,
You have mentioned that you purchased Office 365 through GoDaddy. In this case GoDaddy could possibly be owning the subscription on which they have on-boarded you. If GoDaddy support doesn't have much idea, you can mention this to Microsoft support. From what I understand you will be paying GoDaddy which would take care of billing on your behalf, I guess.
I maintain a family web site on Azure on my spare time. For a small fee, we have purchased a custom domain name to make it more "professional".
Unfortunately, the credit card associated with the susbscription has expired and since I was not actively monitoring the dedicated mail account I had created for this purpose, the susbscription has now been deleted (the susbscription is actually disabled in the portal, but the mail from Azure says that I need to create a new subscription if I want to change my mind).
In a matter of minutes, I registered a new subscription and thanks to continuous deployment, I could deploy the Web App from sources that I had kept on a GitHub account. However, an attempt to bring an external domain to the Web App fails with the reason being that the said domain is already in use by another Azure web site (presumably, the old Web App from the, now deleted, subscription)
A quick chat with the #AzureSupport team on Twitter, they suggested I file a support request from the Azure portal. However, since this is not a professionnal susbscription, I do not have a support plan. I see that support costs 25 $/month for at least 6 months in my situation.
This seems a bit too costly, like an order of magnitude higher than buying a new domain name for several years. At the same time, I don't understand why the deleted account is still locking the custom domain name. And it seems unfair that I need to pay to recover a domain name that I own but am unable to benefit from because it is associated with a Web App in a disabled Azure subscription!
Please, what are my options?
PS: Even though this is not a programmatic question, I post here because that's where Microsoft recommends to obtain community support. I have also posted a similar question on an appropriate MSDN Forum but the answers there are not satisfying.
Unfortunately on a technical level this will be something that can only be rectified by Azure support. Since you no longer have access to the account they will need to delete that domain association.
It is excessive that you are required to pay for a six month support contract to resolve an issue that is clearly an issue with the way Azure decommissions subscriptions.
The problem you now have is that you can't use Azure to host this domain until that association is removed. Your only options are to either have the complexity of using a VM or to move your site to AWS etc.
If you make those points to #AzureSupport team, maybe they will process it for you. Point them to this question and ask them to help you to keep using Azure.
We're completely upgrading our production and development environment from co-located boxes to an Azure implementation and we'll be developing using Visual Studio Online. Up until this point our dev has occurred on a Remote Desktop environment where developers were logging into Windows server and developing on that RDP box.
We want to set this up and we have some confusion about the Account types/set up types.
It appears there are two ways to set up our Azure and two ways to set up our developers. We are a MS partner w/ some MSDN licenses and Azure credits.
So for Azure we can use our existing MS accounts and just set up an Azure Pay As You Go (PAYG) subscription. This was suggested to us initially but it seems weird to have the entire companies Azure environment going through an individuals live ID. Then we saw we can sign up as an Organization now and it uses Azure AD. We have not been using Active Directory and we're not sure how much complexity this is going to add to our administration. Is there a discernible difference/benefit to going one way or the other?
Then, when we sign up our developers we can either have everyone sign up with their live ID's (we have MSDN w/ VS Premium credits for all developers) or we can set them up using Active Directory with Work Accounts. Having our credits allotted in work accounts sounds like a good way to control things at first reading, but it also seems a bit more complex. I'm wondering if there is much difference between MSDN accounts signed up w/ live IDs or AD Work Accounts. I can't find a real comparison article or pro/con type of discussion anywhere.
It sounds like you have already figured out the main differences. As an organization, I would suggest signing up for Azure as an organization. You can do that here. This is going to give you the management capabilities for resources typically needed by an organization.
Your developers can continue to use the MSDN subscriptions. As Dylan commented, these are not to be used for production environments. You should consider using these for Dev/Test environments and activating your MSDN benefits. This will save you some money. More on that here.
Visual Studio Online will work with your Work Accounts and again give you more control over managing your online resources. This link describes the sign-up process for both Microsoft Accounts and Work Accounts. And if you scroll down a bit you will find your original question specifically addressed.
Finally, you can also add your Work Account(s) to your existing MSDN subscriptions if you like. This way you (and your developers) can use the same account credentials when accessing Azure Subscriptions. Information on how to do that is available in this link.
Your Work Account subscription should be limited to personnel responsible for managing your "production" environment.
After signing up for Azure as an Organization, you can add users to the directory as described here. You can also add "external" users using their existing Microsoft Accounts. It's just a few dialogs to add a user.
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.