I run a Linux environment that's setup in an MIT Kerberos Realm. That realm has a one way trust setup that allows tickets for AD principals (from Windows 7 clients) to be accepted as authentication (for SSH and ODBC for Hadoop/Hive).
The problem I'm having is that Windows 7 clients using Kerberos for Windows 4.01 do not seem to be able to use their AD ticket in MSLSA. If I set KRB5CCNAME to a file and obtain an AD ticket independently of MSLSA everything works fine. With KRB5CCNAME set to MSLSA: it does not work. I did find a note about setting AllowTGTSessionKey to 1, but that's already been done (and rebooted).
Is there a way to use the AD tickets stored in MSLSA using MIT KfW?
Try to set hkcu\software\mit\kerberos5 string:ccname value:MSLSA: then
delete the krb5ccname variable and log off and on.
Related
I want to implement kerberos authentication for a software where both the server and the clients run on Windows and are implemented in C++.
When both, the clients and the server are on the same Windows domain it is straight forward to use SSPI and I assume this will work also for cross-realm environments.
When for any reason the server cannot be member of the domain this straigth forward approach will not work.
How is it possible to achieve Kerberos authentiaction against a server that is not member of the domain?
If my research is correct java applications or linux use a keytab file instead of implicitly retrieving the key from AD. Apparently SSPI does not support keytab files. Is there a way to use keytab files in this scenario?
SSPI does not "retrieve the key from AD" – the service key is always stored locally, but with SSPI it's the machine account password which was generated during AD join process (and uploaded to AD rather than retrieved from) that acts in place of the keytab. Windows stores the machine password in LSA and derives the key from it in memory, but it has the same purpose as a keytab file.
There may be a way to store a machine password in a non-AD machine (using ksetup.exe), but it is very much a system-wide change – it seems to make certain parts of the Windows login process function as if the system was domain-joined – so I would not recommend doing so, except in a test VM.
Instead, you can use another Kerberos implementation – MIT Kerberos and Heimdal are the two major non-AD Kerberos implementations that come in the form of C libraries (both are Windows-compatible, though their focus is on Linux/Unix-like systems). Both libraries provide the GSSAPI interface, which is similar to Windows SSPI, and both use keytab files for service credentials.
For C#, Kerberos.NET is available. For Rust, sspi-rs seems to be in active development (it isn't just a binding to Windows SSPI but a standalone implementation as well). Java of course has its own Kerberos implementation built-in as part of JAAS although Apache Kerby exists as well.
Most of those implementations support the same keytab format because they mimic MIT Kerberos to some extent (which was the original Kerberos 5 implementation).
Both MIT Krb5 and Heimdal include not just a library but a KDC service as well, though that part won't run on Windows. (Kerby and Kerberos.NET could also be used to build minimal KDCs.)
The above is more important for servers; however, a client can use SSPI to authenticate to Kerberos services without any requirement to be a domain member.
For realms that are AD-based (regardless of the specific server being domain-joined or not), it is enough to provide a UPN-format username (in the form of user#domain) and a password to SSPI; it will automatically discover KDCs and obtain tickets.
The same works for Kerberos realms that are not AD-based as long as the realm is marked as a "MIT realm" either via registry or using ksetup /AddRealmFlags. (The principal user#REALM needs to be specified as username in this case.) Unlike the earlier mentioned case, this ksetup.exe usage seems to have no negative side effects.
I'm using git over ssh on a remote machine that is running Windows 10. When I try to do a git pull, I get the error message in the title after entering my credentials.
Fixed by installing the latest version of git credential manager on chocolatey (not sure if this is necessary) and switching my git credential store to dpapi.
See https://github.com/GitCredentialManager/git-credential-manager/blob/main/docs/credstores.md#dpapi-protected-files for instructions on how to do so.
This could be illustrated by GitCredentialManager/git-credential-manager issue 325
The error you're seeing is related to the way that Windows handles "logon sessions" and "credential sets".
GCM Core uses the Windows Credential Manager (wincred.h) to store credentials safely on Windows.
We interact with wincred via the Windows APIs: CredRead, CredWrite, CredDelete, and CredEnumerate.
The error being returned in your case here is ERROR_NO_SUCH_LOGON_SESSION (0x520) which means:
The logon session does not exist or there is no credential set associated with this logon session.
Network logon sessions do not have an associated credential set.
The key part here is in bold.
When you connect via SSH, the sshd daemon/Windows service is running as the NT AUTHORITY\NETWORK SERVICE account (most likely/by default), which creates network logon sessions when an SSH client connects.
From some searching online, one workaround posted is to change the account that sshd runs as to be your real user, which would then have an associated credential set. Your milage may vary here depending on setup.
If you try to use the built-in cmdkey command for interacting credentials stores in the Windows Credential Manager, you'll see similar errors or messages like "saved for this login only".
Upgrading to the latest version of GCM comes with:
With the latest GCM Core release (v2.0.567) there is support on Windows to use a different credential store other than the Windows Credential Manager that shouldn't have the same remote-session limitations.
You can read more about the different options here: https://aka.ms/gcmcore-credstores
The specific store that may help this SSH scenario is the DPAPI-protected file store.
Credentials are protected using Windows DPAPI encryption (based on your current user account) and are written to files on disk (configurable; defaults to %USERPROFILE%\.gcm\dpapi_store).
I want to configure internet option via remote for windows 8. For example, I some pcs have two accounts, say admin,user. All pc connected via LAN with a server. How do I disable and enable internet from centralized server for only those users who have logged in via 'user' account? I asked for windows 8 machines.
The best way would be some kind of Centralized authentication and authorization.
Like the Microsoft ActiveDirectory, or An OpenLDAP Server.
Next you would need a proxy server where every program/user has tho authenticate to open up a new Connection to the outside world.
Another approach could be some kind of captive portal on your router (pfsense does this pretty easy and fast) for authentication.
This could also be paired with a centralized user management oder just local users.
Local Users (on every machine) have the problem that none of the settings and properties, such as passwords, could be synchronized and have to be set by hand on every machine.
I have deployed an MVC 3 website on IIS of my Windows Server 2003 edition. I have set the authentication to Basic, Integrated, and Windows in order to enable site to use Windows authentication, and automatically log in into website if the user has launched the site from the same domain. If user access the site from another domain, it should prompt the Windows credentials and should allow user to log in.
However the problem is that, user is presented with Windows login prompt every time (irrespective to same or different domain), and also when user provides valid credentials it doesn't allow user to access the site.
What could be the problem here? Or, can anyone provide me proper guide to configure IIS to use Windows Authentication while deployed on Windows Server 2003?
What is the version of IIS you are using ? Could you try to force NTLM authentication and see whether it will change anything ? Followin technet article will tell you how to change to NTML http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/7258232a-5e16-4a83-b76e-11e07c3f2615.mspx?mfr=true. Please backup the server/iis configs before attempting any modifications to the metabase
I have just installed Windows Server 2003 Standard Edition and therefore IIS6 (comes as standard). I have also install the windows component that enable the administration of IIS from the browser (https://server:8098/). The problem I have is that I have to log-in to this tool but the Server Administrator u/name and p/word does not let me in.
The Windows documentation on this tool (http://support.microsoft.com/kb/324282) says "You are prompted for a user name and password that exist on the Web Server" but none of the standard user acounts on the server let me in.
Thanks,
Here are a couple ideas:
Take a look at the security log on the server for clues.
Look at the "Directory Security" tab on the properties of the admin site and ensure "Enable anonymous access" is unchecked. You will need to use "Integrated Windows authentication" or "Basic authentication". If you use Basic auth then the password is sent across then network base64 encoded - you will want to use SSL to encrypt it.
Is there a specific requirement to use the web tools? You can download Internet Information Services (IIS) 6.0 Manager for Windows XP from Microsoft and run it from a client.
I'm not so sure now, haven't set up a Win 2003 box in a while but as far as I remember you have to activate remote desktop first and then you can use a RDP client to access the server. I recommend that over the ActiveX RDP client.
Is the server part of a domain? It may be defaulting to a domain username/password combo rather than a local username/password.
Try "server.domain.local\administrator" or "administrator#server.domain.local".
I would check the permissions on that site in IIS - make sure you are using an account that is a member of a group specifically assigned permissions. I understand that the builtin admin account is not working but its possible the site permissions have changed removing that account or group. - hope that makes some sort of sense
This might be unlikely, but are you trying to use a username that has a blank password? Windows restricts remote access when using those accounts.
If that's the case, you can check the Group Policy (gpedit.msc for local computer, or the one for domains if it's in a domain.):
Computer Configuration
Windows Settings
Security Settings
Local Policies
Accounts: Limit local account use of blank passwords to console logon only