I currently have a Windows server in which I uses Active Directory to manage my user's account. I want to expose my password reset script functionality to a third party application. How can I achieve this with most optimal security?
Currently, I have written a PowerShell script to automate the password reset. I planned to allow PowerShell remote to allow the third party application to execute my script. But I am not sure how to constrain the third party to only be able to execute the script via the script and if this is the optimal solution.
You can take a look at constrained PowerShell endpoints. You can create a "session configuration" that will restrict what can be done, then also restrict who can connect using that configuration.
I can't walk you through how to do it because I've never done it, but there is a whole series of articles on it here: https://devblogs.microsoft.com/scripting/introduction-to-powershell-endpoints/
Related
I would like to use Project API on top on Workspace API. I would like to test it on a docker installation single user.
The documentation seems to say Project API is secured. Shall I enable security for a single user, or shall I switch to multi-user setup?
I would have hoped to be able to remove security on all APIs in a single user mode
Che in a single user mode does not have any auth checks, so, you can freely call services.
How to use external CyberArk vault to store credentials in free version Jenkins?
Here you can find info regarding the standard jenkins credentials plugin - that provides an API for external storage.
But after digging a while on the net, I’ve found that:
1. Cyberark vault is available on Cloudbees Jenkins only
2. HarshiCorp vault plugin is available for free
3. Here is a nice example how wrong permissions policy can lead to exposing all credentials. I tried it, works like a magic! :)
You really don't want to store credentials (or any sensitive secret, really) in Jenkins. It's not a vault and should never be used as one. Otherwise you'll end up with your Jenkins servers becoming a major target for attackers.
Instead, integrate your Jenkins pipelines to pull secrets securely into executors only when needed, and discarded when the build/test job is done. This is easily done with something like Summon, which is integrated with many vaults already, including Conjur (which is a CyberArk product, too). Both are open source offerings.
This blog post describes an approach to integrating Jenkins with a vault along the lines of what I've described above.
Appears that CyberArk released Jenkins plugin which supports that scenario:
https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/Latest/en/Content/Integrations/jenkins.htm
You might want to look at https://github.com/tmobile/t-vault .
This will eliminate the need to manage policies. You could create one safe per project folder or job in jenkins.
You can create approles and grant access to safe for the approle. Each project can use corresponding approle. You can grant access to individuals to the safe as well. Users can then use the webui to author and update the secrets.
The design of the current app I'm working on calls for a WCF Service, hosted in a Windows Service, that pulls data and stores it on the hard drive. It pairs with a windows forms application that will interact with the WCF Service. One of the requirements is that the end user be able to restart the windows service through the Forms app.
So, I'm guessing this can be done using the ServiceController class... but what about permissions? I don't think we can (or should) guarantee that the windows app runs as admin, and the service is running as a Network Service.
The only thing I've seen that reasonably seems to cover the situation is having another windows service running, which could then be installed under an account with higher permissions, which you could call to restart the target service.
BUT I don't want to add that much complexity to the project, especially since it was supposed to be in beta last week.
So is there a way I can just give the Forms app the necessary permissions to restart it's specific companion service?
The follow-up question is down the line we might make it so the service runs on a server rather than the same machine as the app. Would this make it impractical to allow a Forms app to restart the service? If so I may advocate cutting the feature...
Oh, and should note that the target platforms are WinXP and Win7 with .NET4.
Instead of giving permissions to the app, you can assign permissions to the service to be started and stopped.
Every windows service has a security descriptor that is assigned a permissions what you are allowed to do on the service. By default service has permissions for authenticated users to read services state, and for admins to control the service, as well as delete it.
You can set service security descriptor using command sc sdset <serviceName>. For example this command will allow any user to control service (but only admins and Local system are allowed to delete service or change security on the service):
sd sdset <myservice> "D:(A;;CCLCSWRPWPDTLOCRSDRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)"
You might want to tweak the security descriptor a bit if you want to allow only a specific account to be used to control the service. This would work remotely as well, as long as the remote account is authenticated by the machine.
How about making the service responsible for restarting itself? It could expose a method, Restart(string userId, string password) or something similar.
On being called by an authorised user, it could use the approach outlined in this answer. That is:
Set the service to restart on failure
Call Environment.Exit(1)
OS restarts the service for you.
You would call Environment.Exit(0) if didn't want to restart.
i want some of my users to be able to go home and upload their files from Home PC's by going to say www.mydomain.com/upload
it will ask for their windows username and password then take those files and upload them to their re-directed folder on the fileserver...
im guessing SSL encryption is a start (or probably my last step). Can i do a VB script server ened and a runas - Copy?
Uh... you've got the right idea, but step back a moment.
There are two main options:
* WebDAV - Anyone with a modern OS can configure "Web Folders". Windows will present the network location as a filesystem folder where users can simply drag and drop files to upload them. This requires configuring IIS.
* A web-based file upload script - There are many of these around, however very few of these integrate authentication with IIS and support Kerberos. You do not need TLS/SSL for Windows Authentication or Kerberos, but it might be a good idea anyway. You may need to write your own if you can't find what you want, however VBScript is not appropriate as it has no built-in support for Identity Impersonation or handling file uploads with ease (it is possible, but not very easy). You're better off using PHP or ASP.NET
HTH.
I am developing a web based intranet for my company. I just want to know is it a good thing for users to login the application using the active directory login details or shall i create a login together with the application db.
If there is anything better that this please suggest. This is my first application development so need help from experienced people.
Generally it's a good idea to try and minimize the number of accounts people need to have.
So I'd definately try and use their active directory login.
Also if desireable, you can automatically log people into your application using various single sign on methods. (Either integrated into IIS, or other.).
This makes for a very usable application, as people always forget login details, and hate to login again to other systems.
Only use Active directory for your intranet, if you infrastructure supports it.
You question is phrased as if you think the user to type there password in again to login to the intranet site - they should not do this! have windows pass on the credentials automatically. This is pretty much built in to dotnet/iis/etc.
Also AD will add group management a privledges so you can restrict areas of you intranet to members of certain groups.
And you support team already have the tools to manage all this.
PS you can enable FireFox to auto log on via NTLM and it is one of the most requested features for Chrome too so don't let browser issues put you off
There are several pros using Active Directory authentication in the intranet.
Thoses are the main ones:
You want to to keep authentication stores number as low as possible
Using Active Directory, users who have their desktop in the domain (as they should) will be able to use Integrated Windows Authentication. They will be able to log in without having to type their password.
An Active Directory authentication mechanism probably exists for your language
More information:
http://msdn.microsoft.com/en-us/library/ms998358.aspx
If you create a separate login system, then your users have to remember 2 different logins. Why bother, when their "real" login is right at hand?
Less code for you to write and better integration into the wider system. And, who doesn't want FEWER passwords to remember.
Definitely go for the Active Directory option, or use Active Directory as an LDAP server if whatever language you're using doesn't directly support AD. Active Directory actually makes a pretty good LDAP server.
If there is anything better that this please suggest.
OpenID?...