Is Password-less linux to windows pywinrm connection possible.
Something similar to ssh-copy-id in linux to linux
While I haven't done this myself, as far as I can tell, this should be possible. If the Windows machine you are attempting to access is on a domain.
I HAVE set up smartcard/certificate authentication on domains before. If you add your public key to your account in AD, you can authenticate to your domain account using a smartcard or pki cert.
https://technet.microsoft.com/en-us/library/cc754866(v=ws.11).aspx
I have also used kinit (which is what pywinrm uses for kerberos/domain authentication) to authenticate to Windows servers using domain credentials. Although I did not use a certificate/smartcard to authenticate, from what I have read, I believe kinit (pkinit) will support smart cards and possibly plain old certificate files.
https://k5wiki.kerberos.org/wiki/Pkinit_configuration#Client_identity_on_the_command_line
http://honk.sigxcpu.org/con/PKINIT__Kerberos_v5_with_Smart_Cards.html
Before you can authenticate with kinit, you would need to set up your domains and realms. This blog post is about setting up Ansible to administer Windows machines but, since Ansible uses PyWinrm to authenticate, there is a pretty good walkthrough for setting up kinit for domain authentication (and therefore he talks about how to set up your realms, etc.).
https://aseemkblog.wordpress.com/2016/06/01/configuring-ansible-to-manage-windows-system-over-powershell/
If you ever get this working, let me know. Would definitely be interested to see if someone gets this working. Just getting kinit auth working with Windows domain authentication is a bit of a maze but, once that part is done, you're about 75% of the way there.
Yes, it is possible!
There is a Windows version of ssh-copy-id I found on GitHub:
https://github.com/zhengyi-yang/ssh-copy-id/tree/master/dist
Make sure you have your public key generated already.
Related
I want to build a server using Node.js, which acts as some kind of proxy. The clients that connect to my server use NTLMv2 for authentication (there is no chance to change this), but the upstream server my server shall connect to requires a Kerberos token.
So, my question is pretty simple: How do I, using Node.js, transform the information provided by NTLMv2 into a Kerberos token? On npm, so far I have found modules for NTLMv2 authentication, but I somehow would probably need to talk to Windows to translate NTLMv2 data of a user into a token for this user.
Any hints on this, how to approach this problem?
Absolutely not! NTLM and Kerberos operate completely different. First of all, I would highly recommend get rid off NTLM as fast as you can.
You can solve your problem in an easy fashion if you can access C interfaces. I also assume you MIT Kerberos on a Unix-like OS like CentOS or FreeBSD, etc.
NTLM will provide you the downlevel logon name. You need first to convert the NetBIOS domain to a DNS domain via LDAP (use libopenldap) then you can construct the Kerberos principal or the enterprise principal for your client. Then create a service account in your KDC and enable protocol transition and contrained delegation on that account for the target service. Now request a TGT on behalf of that user principal and request a service ticket for the user, voila you can access your Kerberos backend.
Here is a decent read: https://k5wiki.kerberos.org/wiki/Projects/Services4User
If you run HTTPd as your reverse proxy, it might handle all the magic for your with mod_auth_gssapi.
On Windows, this is a bit of a pain with the security API and SSPI. While the the principal transformation comes for free with Windows. You'll need LsaLogonUser with KERB_S4U_LOGON, impersonate with that handle and then require SSPI to acquire a cred handle...
If your KDC allows constrained delegation, you can setup your intermedaite server to allow impersonation. This way it can established security context with the client in one mechanism (in your case, NTLM), and talk to the backend server on behalf of the client in another mechanism (Kerberos). Google for "constrained delegation" and "protocol transition" for more information. Hope this helps.
I haven't really have had much experience with Kerberos but I am trying to set up SSH authentication with AD on one of my servers using sssd. I have followed the instructions on the sssd documentation here and got it working but I am struggling to understand why I need a keytab file to set this up?
I've been doing a bit of reading about Kerberos lately and it appears you only need to create a keytab file on the server when the server needs to authenticate to AD without user interaction or when you need to implement SSO (when a user requests a ticket for that service).
I simply want my users to enter their username / password when logging in via SSH and have sssd authenticate this user against AD and create a TGT ticket for them. The funny thing is - even when I don't setup sssd and only set up the kerberos side I can run kinit and I get a ticket!
So my question is this: Can I set up SSH authentication using sssd without generating a keytab file on the server? if not then why not?
Your question in the Subject line "What is the reason for a Kerberos keytab file when setting up SSH authentication on a server?" boils down to a one-line answer: it allows for Kerberos single sign-on authentication to the Directory server by de-crypting the inbound Kerberos service ticket to "tell" who the user is. As far as your other question, "Can I set up SSH authentication using sssd without generating a keytab file on the server?", the answer is yes, you can. But you will be prompted for a username or password whenever you connect to the SSH service, unless you choose to cache the password in whatever SSH utility you might be using to connect. Caching the password though, in such a method, is not considered to be "single sign-on".
For additional reference, you can read more about my article on Kerberos keytabs on Microsoft Technet: Kerberos Keytabs – Explained. I frequently go back and edit it based on questions I see here in this forum.
I am trying to implement 2FA for logins on my ubuntu machine to increase security alongside with an encrypted home folder. I've opted to use the google authenticator pam module as this also works offline. I've followed the documentation on google's GitHub repository https://github.com/google/google-authenticator/blob/f2db05c52884e4d6c3894f5fd2cf10f0f686aec2/libpam/README.md but it seems to me that you can easily by-pass the MFA as:
the settings are saved in a .google_authenticator file
the settings file contains your secret key that you can use to add the account to the google authenticator app to receive OTP tokens
the .google_authenticator file must sit outside of your encrypted folder as otherwise you can't login
therefore if you boot directly into a root shell (recovery). You can get the secret key from the file and thus bypass the second factor.
Therefore I have the following questions:
am I missing something in the google authenticator set-up?
are there any other solutions that would work offline and can not be so easily bypassed?
therefore if you boot directly into a root shell (recovery)
There is a reason for that, and the reason is as you mentioned above -> recovery.
So, you are not missing anything, except the scope of 2FA: yes it can be bypassed if you have direct access to the server, but it secures remote access (SSH) perfectly fine. Unfortunately there is no way to disallow that.
I've got server with w2k8 and IIS7 in one domain and keytab from some other foreign domain (no trusts). Is it possible to enable Windows Authentification (SPNEGO/Kerberos) to auth users in Web Application from the those foreign domain?
It's theoretically possible, but the logistics of making it work are next to impossible to implement.
I've no idea if IIS supports this or not, but it is possible in the kerberos API to say
"try to decrypt this response using every key in the keytab". In theory, this can be used
with keys from remote realms, although I've never seen code attempt it.
However, the problem is the client needs to decide the realm and principal to use to make
the request based on information outside the protocol. Thus you'd need to somehow tell all the
web clients from the remote domain to use the remote domain when contacting the webserver
in the w2k8 domain. You can do this with krb5.conf on unix machines, but it would require a
custom krb5.conf on every client using identities from the remote realm.
In general, kerberos will only work across multiple realms if there is some kind of cross realm
trust enabled.
I'm trying to write a script which takes a username via argument and password via stdin. I'd like the script to contact the kerberos server and verify the password. I'm going to use this to authenticate perforce users via an auth-check trigger. I'm not too wedded to any particular language although bash and perl are already installed on the (centos 5) system concerned.
Any hints/suggestions would be much appreciated.
Thanks,
Fenster
This Perforce article has some useful links to get started.
http://kb.perforce.com/article/74
I think Kerberos saves a ticket on the machine you're authenticating on, so perhaps Perforce's SSO framework would be better. Check out this project:
http://www.assembla.com/spaces/sso-p4/wiki
Be aware that effectively verifying a password requires more than just doing kinit (an AS exchange). That is open to a KDC spoofing attack: the attacker hands you a password, then redirects your KDC request to his own KDC which says the password is OK.
The usual way to guard against this is for the verifier to have a service principal of its own; it kinits the user's principal, then uses the acquired TGT to obtain a service ticket for its own principal and verifies that ticket. This ensures that it is talking to the same KDC.
Just come across pwauth on google code. It can be configured to verify system passwords using the pam interface. It looks like its been designed with apache in mind but should work for any scriptable situation. Going to try and set this up this week. Will report back when i've tried it.
NB there are risks with exposing your system accounts so the link directs you to the risks page first.