Is it possible to create a user with permissions of both a local administrator and NETWORK SERVICE?
I've got a Sharepoint timer job which runs stsadm for which it needs local administrator permissions. On the other hand temer jobs are also used by other services which need NETWORK SERVICE permissions and those to sets of permissions only overlap, so I need a user with the "sum" of the permissions to run OWSTIMER under.
(I know that most of the operations you can perform with stsadm sharepoint administration API can be used, by in my case it is the operation which moves a site collection between content databases for which there seems to be no API equivalent).
I recommend always using domain accounts - SharePoint works best on servers connected to an Active Directory server. For production environments a best practice is using a least privilege account. I always create the following domain account dedicated to SharePoint services:
DOM\spservice
You do not need to grant any special privileges to this account as SharePoint will automatically do this for you when you specify the account during setup.
I can't help you with the user permissions (Lars hit the important points), but I wanted to share some information that may be of use.
You mentioned that you're trying to move site collections between content databases and haven't found an API the can be leveraged. Have you looked into SharePoint's Content Deployment API (also know as the PRIME API) to see if it can assist? The types of which I'm speaking are located in the Microsoft.SharePoint.Deployment namespace, and they provide you with mechanisms to export (via SPExport) site collections as CAB files and then import them (via SPImport).
SharePoint leverages types in this namespace for its own content deployment paths and jobs (in MOSS); it's also the API that is leveraged by the STSADM.EXE executable for export (STSADM.EXE -o export) and complementary import operations. For that matter, it's also used by SharePoint Designer for it's site "backup" and "restore" operations.
For an example of how this API can be leveraged, check out the SharePoint Content Deployment Wizard tool on CodePlex (http://www.codeplex.com/SPDeploymentWizard).
I hope this gives you a potential alternative to shelling out to a command line in your timer job!
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.
We're using Azure to maintain our development and QA servers.
One of the needs we have now, is to provide our QA members access to update web.config file on the server, which can be achieved via Visual Studio Server's Explorer (with the right configuration).
The problem is that you need a user with a subscription as a co-administrator within Azure (at least as far as I managed to understand), but obviously we'd like to allow our QA members only to maintain the files, with limited access via Visual Studio.
Is there any way to do it?
Following Brendan advice, I've granted the QA members FTP access. This should do the job for now, until Microsoft will come up with something better :)
Thanks Brendan!
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.
Whats the best way to deploy a webpart in WSS3 or MOSS2007 which has a database dependency? Should the .wsp include code to create the database, should I encapsulate the .wsp in another installer which handles the database creation, or should I supply two different packages to allow the admin to handle the backend creation?
Well, I prefer the SharePoint way where you create the databases from a SharePoint admin page in Central Administration. Just take a look at how SharePoint handles the creation of new Web Applications where you are asked to name the database server and the name for the SharePoint content database.
In other words, I would opt for a WSP only deployment. The WSP should include a database configuration page (an ASPX page) plus a farm level feature for installing a custom action link to the page inside Central Administration. The beauty of doing it from Central Admin is that it runs in a context with privileges to create new databases on the SQL server. Hence, you do not need to ask the user for login and password to the database server.
The configuration page should upon successful creation of the database persist the connection info in the SharePoint configuration page, using a custom derivative of the SPPersistedObject class. Web Parts can in turn read these settings to connect to the database.
MSI installers should in my opinion be avoided when designing SharePoint apps.
What sort of client is your webpart aimed at?
I imagine it might be worth being slightly flexible in your approach and considering multiple methods of installing your webpart.
So for someone without a dedicated DBA it might be best to have one .wsp.
(Although this should be robust enough to handle superuser's installing it.)
Alternatively go for a .wsp and a msi (or even scripts), which will give the installer
more control over exactly how it is installed.
(I'd prefer this approach, over the .wsp only approach.)