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
Related
I am working on a project that needs to have a Onedrive folder that it owns where it can store and edit certain files. This folder also needs to be accessible through Onedrive to certain users in my organization.
I have created an App Registration in Azure AD, but can't figure out what permissions and configuration I need to achieve this. I know I can give it access to authenticate to a user and edit/create files on their behalf, but I don't want the folder/files to be associated with any particular user in the organization. How can I achieve this?
You might try creating and managing items using application credentials. Also take a look to permissions and shared for more information about making it accesible to others.
Are the files you're looking to store files that are visible to users or that are "data files" for your app? We don't currently recommend building apps that only store their own proprietary files rather than operating on visible user data. (It's a little more nuanced situation when you look at lists rather than libraries of files).
In general files that are expected to be shared among users without a single user owning them would be placed in a SharePoint site. You can then manage the permissions of the site to give access to the users that need the files. OneDrive for Business is specifically intended for files owned by an individual user.
At the moment we don't have provisioning APIs available through Microsoft Graph to create a site programmatically today, but you can look at the PnP Provisioning Engine for how to automate the process with legacy APIs, or if you really just need a single site you can create the site manually and then refer to it from your application.
The Drive API is the same whether you're accessing a OneDrive for Business or SharePoint site.
Azure allows partners to manage customer's resources.
But as startups serving enterprise customers, we might be asked to install our software on customer's Azure Linux server resource and manage it, but we dont want them to access the Linux box via shell or clone it entirely thereby making a copy without our knowledge. How do you solve this?
For the install, I'd write a bash script to install your application by wget'ing the binaries and setting some environment settings. If you want to take it a step further, your client can create an ARM template that spins up the VM and installs your app via custom script extension. When it comes to managing the application, you should be able to view log files in Azure using Application Insights and perform administrative functions using the app. If an issue arises that cannot be diagnosed from the log files and the built-in app diagnostics (e.g. the install failed, app cannot write to log files in local dir), I'd do a screen share with the client and troubleshoot.
You could create a web application that would talk to the OS and perform the administrative tasks you wish. This way, you only need to open one port (possiblity 443 - HTTPS) and share login credentials w/ your partner. This way your OS is protected -- administrative tasks can only be performed through a web UI.
By doing a quick Google search, you can find some open-source options:
http://ajenti.org/
http://www.webmin.com/
https://cockpit-project.org/
You need to ensure you create users for your customer with limited access. Get Webdmin as an example: https://doxfer.webmin.com/Webmin/Webmin_Users
A standard, out-of-the-box Webmin installation has only one user
(called root or admin) who can use every feature of every module. On a
home or office system used by just one person, that is all you need.
Even if your system has multiple users, there may be only one who
needed to perform system administration tasks.
However, there are many situations in which the administrator may want
to give some people access to a subset of Webmin's features. For
example, you may have a person in your organization whose job it is to
create and edit DNS zones and records. On a normal Unix system, this
person would have to be given root access so that he can edit the zone
files and re-start the DNS server when necessary. Unfortunately, once
someone is able to login as root he has full control of the system and
can do whatever he wants.
Webmin solves this kind of problem by allowing you to create
additional users who can login, but only access a few modules. You can
further restrict what the user can do within each module, so that he
cannot abuse its features to perform actions that he is not supposed
to. Because Webmin still runs with full root privileges even when used
by a restricted user, it still has access to all the configuration
files and commands that it needs.
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.
Here is a situation I am currently addressing. I am working on a Web project with its security being tied up with the Active Directory. Which means technically when you add a user through the application we are adding a new user to the Active Directory on the Server. Now my question is, is this a good practise?
At this point I think of a vulnerabilty which is you could do a remote desktop on to the deployment server with the account you created through the Application (Please correct me if I am wrong). But I just want to confirm this before I could inform this to my Architect.
Any suggestions will be deeply appreciated.
Awaiting your response.
If the web application has permission to create accounts in Active Directory, then this means that the web application presumably has an account with (possibly limited) administrative rights to the Active Directory domain. That could potentially be used for all sorts of bad things if you're not careful.
If you're going to proceed, then the first step, if you haven't already done so, is to delegate administrative rights to your web application's account so that it can only create accounts within a particular OU. See this article for details, or search Google for other descriptions.
You'll probably also want to set up Group Policy and group memberships to further restrict the newly created accounts (for example, disabling Remote Desktop), and you'll want to do so in a way that doesn't rely on the web application doing the right thing (as an extra layer of security in case the web application is compromised).
ServerFault would be a better place to find out about Active Directory's security model and how to best set up these various restrictions.
Finally, if you don't need to have users automatically created within your Active Directory domain, then you should consider other approaches. If you're only looking to use Active Directory as a stable, robust source of user authentication, for example, then you can use Active Directory Lightweight Directory Services (formerly known as Active Directory Application Mode) to get Active Directory's functionality without any affect on your domain's security.
Why do I need to create Multiple SSPs in MOSS?
My manager (sharepoint administrator) asked me to create another SSP which he wanted to use for TOP Management users. He didnt tell me what was the reason for it.
I was wondering what all scenarios we need to create Multiple SSPs. Any ideas?
Very vague question, please add more info!
And as a general answer, you don't need to, the concept is to share the services under the SSP between multiple web applications, what scenario do you have to need to create more than one?
Edit after question update:
An SSP host the services that will be used ( consumed ) by any associated Web applications. These services include :
Profiles
Audiences
Business Data Catalog Connections
Search and Indexing
Single Sign On
Excel Services
Usage Reporting
Source
So if your manager won't actually have something special on any of those services, I don't see a reason to do it. We had a customer once that needed the entire mysite and profiles customized, so we created a SSP just for that one web application.