i have this situation:
windows domain (+active directory) (2008),
linux machine (debian, redhat),
and windows work stations (xp, vista, 7).
users are connecting to linux from win PCs using ssh (putty). thah means, thay must type username and password on every login.
my goal is create SSO. users login to windows(and domain) on startup (by domain name+pass), and when they are connecting to linux machine no password is required. i need configure linux machine. and make same changes in putty-core application in worstations. biggest problem is configure linux.
need some help
maybe using kerberos??
thanks
Best would be to use Centrify DirectControl Express and Centrify Putty (both FREE). Centrify DirectControl Express allows you to quickly and easily join a non-Microsoft system to an Active Directory domain, thereby giving you the advantage of a single administrative tool to administer authentication across a heterogeneous computing environment.
Distribute Centrify-Enabled Putty to your windows users, to be able to SSO into the Linux machines.
For more information, refer to:
http://www.centrify.com/express/centrify-directcontrol-express.asp
http://www.centrify.com/express/centrify-enabled-open-source-tools.asp
Related
I have below setup in my office
2 AD servers
1) corp.mycompany.ney
2) mydevenv.net
Client machines
1) Windows-1
2) Linux-1
My Windows-1 machine is in doamin of mydevenv.net and I am also able to log with user-account of corp.mycompany.net domain
However I can't do it with Linux-1 machine.
My Linux-1 machine is in mydevenv.net domain and I am able to login with user-account of mydevenv.net but not with user-account of corp.mycompmany.net
Is there any way to do that?
Note - I used Powerbreaker Identity Services (PBIS) to joine Linux-1 machine to Domain
However I can't do it with Linux-1 machine.
What errors you're getting?
Do the domains have trust? Is the cross-domain trust setup as mutual?
What are the compatibility levels in both domains? If one for example is 2003 and another 2008, then Kerberos tickets validation would be one-way as for example 2008 has more encryption types that 2003 "Function Level" doesn't support/
Read more on this here:
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/understanding-active-directory-domain-services--ad-ds--functional-levels
You may also need to craft /etc/krb5.conf on your Linux server to describe domain controllers for both domains in realms and/or domain_realm sections.
I've got 2 machines:
A corporate desktop machine which is running Windows 7 SP1 which resides on the corporate domain and which I log into using a corporate domain account.
A personal laptop that I use when working from home via the Cisco VPN client but presently sits on my desk connected to the corporate WiFi (though I had it connected to the wire and on the same subnet as my desktop machine today also). This machine is not on the corporate domain; I log into this machine with a Microsoft Account.
I need to run Visual Studio 2013 Release Management Client from both machines. The machine on my desktop works fine when entering either the IP address or the URL into the Release Management Server URL entry field and everything hooks up and all is glorious.
On my Windows 10 laptop however, it's a different story. Every attempt to connect is met with the error:
The server specified could not be reached. Please ensure the
information that is entered is valid (please contact your Release
Management administrator for assistance). <-- I'm the admin
I can ping the machine both with IP address and with hostname, ruling out DNS issues. Both client machines are on the same subnet. Both machines are using the same outbound port.
Checking the event log I see a bunch of Message: The remote server returned an error: (401) Unauthorized.
Checking with Fiddler, on my desktop machine, I can walk through the handshake of each of the stages of startup and all is good. But in Fiddler on my laptop I see 3 401 Unauthorized errors before Release Management Client bombs and returns the rather uninformative message I posted above.
I've attempted to create a shadow account on my laptop and do the Shift-Right Click-Run As Different User dance, but I must be missing something because I can't get this to run.
I've talked to the network administrator who suggests that I should be able to access all of the same resources from both machines and that it must be a Release Management issue.
Is this an incompatibility between VS2013 Release Management & Windows 10 or something else? Has anyone else had this issue and overcome it? I have access to be able to administer the Release Management environment if there's changes that need to be made there and I'm a local administrator on both machines. I'm not however a domain administrator if changes need to be made there.
I would bet you simply have a security issue as the workstation is not domain-joined and the WPF client is using Integrated Authentication.
Often creating a local "shadow" user with same username and password, and running the client app under that account (run as) works.
Another option is to join the workstation to the domain or use a domain-joined VM.
After fully investigating the situation, it appears to have been a combination of factors. I am posting a response because this appears to be a relatively common problem:
The workstation was sending an unexpected credential to the server. To get around this, you have to configure the user account on the server without a domain in the username and create a shadow account on your local machine. When running the client application, you must either log into this shadow account on the local machine or you must SHIFT+RIGHT CLICK and choose "Run as" entering your local shadow credentials. This will then pass the shadow account to the server which will now authenticate without referencing the domain. OR
Create a user account on the server that matches the credentials on your local machine including MACHINENAME\LocalUsername
There appeared to be a network issue when attempting to connect to the Release Management Server from the non-domain machine when connected inside the network. When connecting via the VPN from home, this situation was resolved, but only after we'd ensured the account and local machine accounts were correctly configured. The domain connected machine always connected properly.
Is it possible to setup a virtual machine on Azure and have that same instance of the virtual machine visible to multiple users?
We are an ISV. Our users are scattered globally. We would like to use an Azure virtual machine to guide users though setup of our software. Ideally our helpdesk would demonstrate our software on the VM while the new user looked on.
The software is ultimately installed on the users local machine. The virtual machine is just for offering support.
We see this as a potential alternative to a product that allows the helpdesk to remote into the user's machine.
Yes. You can just use the users and groups dialog in Windows Server to create multiple users, and then give those users Remote Desktop access. This isn't specific to Azure though, it's just the capability of Windows Server.
See: https://technet.microsoft.com/en-us/library/cc732336.aspx
On the other hand there is a limit for user quantity by default. See
https://serverfault.com/questions/549297/how-to-enable-the-2-concurrent-1-console-sessions-on-windows-server-2012
Our VisualSVN server has "Integrated Windows Authentication" enabled, so I cannot access to it via Ubuntu/svn.
When I do this :
svn checkout http://MyRepo
I get these errors:
svn: E120191: Unable to connect to a repository at URL 'http://MyRepo'
svn: E120191: Error running context: The requested authentication type(s) are not supported.
Does anybody know a solution to this problem (other than not using Windows Authentication) ?
If you have Integrated Windows Authentication enabled, then your client computer has to be joined the Active Directory domain where VisualSVN Server resides (or at least trusted AD domain). In such case Integrated Windows Authentication will work from the Linux machine (over Kerberos or NTLM) without any problems.
For a non-domain Windows machine, it is always possible to put AD credentials to Windows Credential Manager and you could authenticate over IWA without any issues. I don't know any alternative on Linux for the tool but I guess that there has to be one.
You can enable Basic Windows Authentication in VisualSVN Server settings in addition to Integrated Windows Authentication. This way Linux-based should be able to authenticate over Basic.
Objective:
Setup Git repository on Oracle Linux 6. Users connecting from Windows, Mac and Linux, using AD credentials. I would like to limit access base on AD groups. I have been searching for a way to set this up. I have seen several options that allow for fine grained access control of the repository but I haven't found anything that can use AD groups to manage access.
So the question is: Is this even possible? Can someone point me in the direction of documentation that would explain the process?
Update:
There now appear to be more options:
GitLab supports LDAP authentication
Gogs supports LDAP too
Update:
GitBlit, "an open-source, pure Java stack for managing, viewing, and serving Git repositories", supports LDAP authentication out of the box:
LDAP can be used to authenticate Users and optionally control Team memberships. When properly configured, Gitblit will delegate authentication to your LDAP server and will cache some user information in the usual users.conf file.
GitBlit also lists support for Windows authentication, but only when installed on Windows, and only tested against local accounts.
Previous answer:
If you move your Git server to Bonobo Git Server on Windows you can use Windows authentication:
Windows Authentication
This authentication is very useful when your git server sits inside the company network and your accounts and logging information could be managed via IIS. The advantage of this approach is that your users won’t have to create another account for logging to Bonobo Git Server. They will use the existing Windows account they use on the network.
Doing this from Linux is possible, but unlikely to be easy. You'll probably have to set PAM up to use either LDAP or Kerberos authentication and then do quite a lot of configuration. If you've got Windows licences I strongly recommend checking out Bonobo.