I know of a TFS 2010 server which i can connect to just by creating a TfsConfigurationServer, without setting any credentials.
TfsConfigurationServer configurationServer = new TfsConfigurationServer(new Uri("address"))
After connecting, I am able to retrieve all the team project collection and corresponding team projects. Isn't this a security vulnerability? I am not sure as I am new to TFS api.
Will every TFS server allow to list the team projects like this? If this is a vulnerability how to fix it?
It's probably not that you're not using any credentials, it's that you're not explicitly specifying any credentials. In this case, your logged-in user credentials will be used and you will be logged in without needing to type your username and password.
One of three things is probably happening:
You are logged in to your workstation as a domain user. The TFS server you're connecting to is joined to a domain with a trust relationship to the domain that you're logged in to. Your domain user has appropriate permissions to connect and query the list of team project collections.
There is no trust relationship between your computer and the TFS server, but you have an identical username/password configuration on your workstation on the server. (Ie, you're using "shadow accounts" or "mirrored local accounts".) Your user on the TFS server has appropriate permissions to connect and query the list of team project collections.
You have credentials saved for this host in Windows Credential Manager. Those credentials have appropriate permissions to connect and query the list of team project collections.
If one of these two things is not true, you would instead need to provide explicit username/password credentials to an account that has permissions to connect and query the list of team project collections.
It may be possible to turn on anonymous access in IIS and allow guest users access to list the project collections in TFS, but I don't know of anybody having done this. I've never tested this scenario myself.
In any case, if you're looking at a server that has this functionality enabled, it is indeed not the norm.
Related
since anypoint platform url anypoint.mulesoft.com is publicly accessible anyone can access the resources. Is there anyway i can restrict access to my org users apart from creating access roles.
Can i create org specific url with org secific access so that others cant access?
Can put some network related restrictions?
I think you confusing two different things:
Accessing a public URL (ie https://anypoint.mulesoft.com)
Authorization inside your organization's account
You can not restrict access to a site that you don't own, it is publicly accessible and needs to be accessed by other users. It doesn't even make sense really. Would you attempt to restrict access by others to google.com or twitter.com (or their API URLs)? It is not the right approach and it is just not possible.
What makes sense however is to manage permissions inside your organization in Anypoint Platform. It means when an user belonging to your organization logs in you can manage what of the available roles are permissions that user will have. You can do that in the Access Management page. You can also create custom roles with specific permissions and teams to better organize your users.
As mentioned you are not able to change MuleSoft's main URL (ie https://anypoint.mulesoft.com), one option being to control from Access Management page, both mentioned by #aled
There are two main ways you can get what you need:
If your organization already has some MFA tool that requires you to be in your corporate VPN, you could use that MFA as the MFA for the Anypoint Platform e.g. Users will need Username/Password, connect to the VPN to be able to get access to the MFA generator/auth and then use that code to finish logging into the platform. As Admin in Anypoint Platform you can enforce EVERYONE to have MFA set up (keep in mind ClientApps authorization for your automation users)
If your company already has an Identity Provider you can configure identity management in Anypoint Platform to set up users for single sign-on (SSO). The fragments below extracted from the official docs external-identity:
After configuring identity management, you must add new SSO users using your external identity management solution and internal provisioning process. If you use the Invite User feature to add users to your organization after you have configured an identity provider, the credentials for these users are stored locally in your organization rather than with the identity provider.
Users that log in with SSO are new users to the system. If the new user has the same username as a user that already exists in your Anypoint Platform organization, the new user co-exists with the original user with the same username. Users with the same username are managed independently from one another.
Couldn't find anything online about this, but I'd like to give a SQL Server role access to a linked server using a specific login to that server. I know you can assign a specific local login to a linked server login with sp_addlinkedsrvlogin but I'm not looking to do this for every login (nor am I looking for a script to do it for every login). I suppose there's some security reasons to prefer the use of an account, but I'd like to know if it's possible.
Not exactly possible, no.
To manage group-wise access, you're supposed to use the Be made using the login's current security context option (doc here). Then, if you're authenticating with Windows authentication, configure the login and user and security access on the remote server with a Windows group that your users are a member of. (If you were using SQL authentication, you'd need to have a login with an identical password on both servers to use this context.) Then you'd have to create the role on the remote server, assign permissions to that role, and assign the group to that role.
This is kind of a pain, but it does mean that no matter how your Windows users connect to the second server, they'll get the same access.
Context
A company that uses Active Directory for a long time. Previously, admins added Domain Users Group to many resources with read access. It is not realistic to change all this.
A service, in this case a GitHub:Enterprise instance, that uses LDAP for authentication was introduced for a cooperation project with another company.
Problem
Creating AD accounts for the external users gives them access to many resources which they should not have access to. If we don't create AD accounts for them, they cannot access the new service.
Is there a way to create a kind of 'decorated' proxy for AD that has some local users (the external guys) and refers to the original AD db for other users (the employees)?
What other ways are there that could solve the access permission problem?
It is possible to set up an additional VM with either Windows or Linux to solve the problem; however, it would be preferable if that was not required.
Typically this would be done with SAML federation.
Or you could use your openLDAP and add all the users into it as this would not allow permissions for AD.
I have my sql server 2008 setup with mixed mode authentication. I went into sql server and added a new login and referenced an active directory user.
But it seems like all the windows authentication based stuff only ever works with whatever was used to login to the operating system. So I'm outside their domain on my machine and I can't connect. But even if I remote desktop into the server itself, using a seperate remote desktop login, even on that machine, I can't login using the active directory user since in the login box, if I choose window auth, I can't specifiy a different name, and sql server auth says invalid login. I don't see how to supply a windows username and password JUST when logging into sql server.
And also, what about my .net apps? I don't want to hardcode a sql server auth username/password into my encrypted connection string, i want to hard code a windows active directory username/password into the connection string.
And then reporting services, aarrghhh.. Does reporting servies ONLY work with windows logins? If so, then I'm stuck with getting the above working. If not, how do I configure a sql server login to also let me access all our reports?
This is a really broad question; I'll give a survey of some of the different topics you address. I work in a hosting provider and we have many domains with no trusts between them, so I deal with this on a daily basis.
Yes, SQL Server Windows authentication really wants to use the credentials running the client application. You can work around this with the RunAs /netonly switch:
runas /netonly /user:domain\username “C:\Program Files (x86)\Microsoft
SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe”
Authentication for .NET apps is a big topic. Lots of options and chapters, if not books have been written on this.
Regarding Reporting Services: most of this access is through a browser. So this will use whatever credentials you supply to your browser. In IE this is controlled through the security zones and settings of whether your current credentials should be used or if you should be prompted.
Some clues:
If you're external user and SQL Server is in mixed mode it will be easier for you to have SQL login not mapped to AD user (so you use SQL auth and not Windows auth). You may have two SQL Logins - one for Windows auth, second for SQL auth.
If you don't your .NET apps have hard coded passwords use Windows auth and Trusted Connection mode in your ConnectionString. If your .NET app is a service create dedicated AD user then create SQL Login mapped to this AD user. Give your SQL User mapped to SQL Login permissions whatever it needs. Run service in context of dedicated AD user. If app is directly executed by users (.EXE file) also use Trusted Connection. Create AD security group for your app users. Create SQL "group" Login mapped to this AD group. Give your SQL "group" User mapped to SQL Login permissions whatever it needs.
It's not possible to provide login and password for SQL Login with Windows auth in ConnectionString. You use TrustedConnection for Windows auth and login/password for SQL auth.
You may play with switching context inside SQL session - EXECUTE AS, see: http://msdn.microsoft.com/en-us/library/ms181362.aspx
We are developing a self registration app.
Our app allows users to register for web apps and is deployed on a weblogic 10.3.5 app server. The weblogic is connected to a local ldap system.
Once the user registeres with our app we call corporate servces to generate a user id. password activation, authentication is all handled by the corporate servcies. which also has a corporate ldap that contains all users in the company.
The approach works fine for 'new users' ie users that are not present in the corporate ldap or the local ldap: users enter their details and are issued a user id which we then copy into the local ldap once the user activates their account.
The use case we're grappling with at the moment is how to handle 'existing' users that wish to register. These are users that are currently in the corporate ldap and wish to 'register' with our applications. They get rejected during the normal registration process as they already exist in the coroporate ldap.
What i'd like to do is force them to login (simply so they don't register on behalf of somone else) and once they're logged in simply copy their data into the local ldap.
The problem is even if they are successfully authenticated by the corporate service, they don't (yet exist) as far as the weblogic server is concerned. is there a way to obtain the user id that comes with the authentication token ?
The authentication method is SAML 1.1
The application is a standard Java EE servlet based webapp using the struts2 framework.
Any ideas would be much appreciated.
Within WebLogic, you can define multiple authentication providers and set them up in the order you would like the system to use. Since you are copying data over, you would have to programmatically check for the existence of the account before attempting to create it on the LDAP server.
It would be a lot simpler if you use the external LDAP server directly instead of copying the data to the internal LDAP server, letting you attempt logging the user in and creating the account only while catching the appropriate exception.