I'm currently learning about Kerberos and all the details of it. Learned how to set up a Kerberos KDC and admin server on Ubuntu, and I can now create user principals and get a TGT using kinit etc.
What I didn't get is how does an application authenticate users. I get the theory, but I want to see it in action. So what I want to do is write a small HTTP application in Linux (C/C++) and have it authenticate users based on Kerberos tickets.
I've been searching the web but couldn't find anything. Could someone give me a hint where to start?
Turn on Tracing for kerberos on Linux this is easy: (do this first it will start giving you feedback)
env KRB5_TRACE=/dev/stdout
Then you could use Curl as #Michael-O said, but with verbose logging turned on that would help you get a feel for things. (as described here)
Check curl version
$ curl -V #- It should support the feature "GSS-Negotiate"
Login using kinit
$ kinit
Use curl
$ curl -v --negotiate -u : -b ~/cookiejar.txt -c ~/cookiejar.txt
http://localhost:14000/webhdfs/v1/?op=liststatus
"--negotiate" option enables SPNEGO
"-u" option is required but ignored (the principle specified during
kinit is used)
"-b" & "-c" options are used to store and send http cookies.
SPNEGO is a authentication mechanism that knows how to facilitate kerberos via GSS-Negotiate. THis would be the fastest way to get a feel for things but it's a lot of logs and not always the most clear.
What I didn't get is how does an application authenticate users. I get the theory, but I want to see it in action. So what I want to do is write a small HTTP application in Linux (C/C++) and have it authenticate users based on Kerberos tickets.
For the server, I would choose one of these options:
Apache with the mod_auth_gssapi module (not the old mod_auth_kerb... but it works too),
or Python using Flask and flask-gssapi (good choice if you want to see how the underlying gssapi functions are used).
There are several others, e.g. Golang's gokrb5 has an SPNEGO example.
In all cases, the GSS-API (or the Windows equivalent, SSPI) will be used on both the client and server, starting with gss_init_sec_context(). The "direct" Kerberos functions are generally not used in programs (except old ones that predate GSS-API).
(Note that normally GSS-API produces raw Kerberos tokens, but with HTTP Negotiate auth they're wrapped inside SPNEGO tokens, so you have to specifically request the SPNEGO mechanism when initializing GSS-API.)
Use curl, it has everything builtin.
Related
Is it possible to create Realm through the CLI - GUI?
I would like to know if it is possible to create a realm via CLI - GUI. (I started the gui with the command “. \ Jboss-cli.sh --gui”)
If possible, how can I do this?
Thank you
Pretty certain you can't use the Jboss-cli for that, but you can use kcadm.sh to manage realms and clients. See official docs.
It just uses Keycloak's rest endpoints, so you could use another tool to make those requests if you wish e.g postman/newman.
However if you require a GUI, why not just use the web based admin panel?
If it is running on a remote server you can use ssh with the -N flag to forward the remote port to some local port which you can access with your browser.
I’m automating a service that needs to access a kerberized resource.
Passwordless kinit with a keytab works fine. The resource is then connected
to using SASL.
Is there a way, maybe via GSSAPI or libkrb5, to ensure a TGT is present
whenever the resource is being accessed? Forking kinit before every access
seems the pragmatic thing to do. However, there’s an obvious race between the
time of TGT acquisition and its use to acquire a TGS that I’d like to avoid.
I imagine something like receiving an fd for authentication whose validity is
guaranteed until it is being closed by the user.
I’d prefer to stay away from heavy-duty solutions like sssd to auto-renew the
TGT.
The answer turns out to be providing the client keytab for libkrb5 in the
KRB5_CLIENT_KTNAME parameter:
If no existing tickets are available for the desired name, but the name
has an entry in the default client keytab, the krb5 mechanism will
acquire initial tickets for the name using the default client keytab.
From the MIT Kerberos docs.
The wiki also has a write-up of the implementation.
I'm using moodle 2.7 ,i need to use LDAP authentication for allowing users to login using external LDAP server(with their username and password).i have tried with the apache directory studio.But i got "Invalid login" error.But the login details were correct.
Please suggest me with some other LDAP server and how to add user details in that server and do authentication in moodle.
FusionDirectory is a reasonable alternative. It's based on OpenLDAP and it's pretty well documented.
Assuming that you're in a Linux environment, you can install it relatively easily/quickly via SSH. Once the download is complete, follow the on-screen instructions which is not that wildly different from setting up any odd CMS/LMS. The default URL is yourdomain.url/fusiondirectory.
When that's all done and dusted, you'll be taken back to the login page where you can sign in for the first time using the credentials you created during the set up process.
You can use your dashboard to add users/groups.
Once you've got a few users in there, it's now time to jump back to Moodle. Hop over to Site Admin -> Plugins -> Authentication -> Manage Authentication and enable "LDAP Server" then open up its settings. Fill in the details of your LDAP server such that it matches the details of the FusionDirectory.
This will set up the connection, but you will finally need to set up a cron job to regularly sync your databases together. Jump to SSH or cPanel->Cron jobs (Whatever option you prefer) and run the following crontab:
wget -q -O /dev/null https://yourdomain.url/auth/ldap/cli/sync_users.php
It's up to you how frequently you choose to set it.
HTH.
I feel like this might be answered already somewhere, but no one seems to have answered this question directly about Drupal and I'm wondering if that might be making all the difference.
I have setup a vanilla Drupal installation with just the necessary modules to use a REST server to handle Push Notifications. In testing the REST server with the CocoaRestClient (found here http://code.google.com/p/cocoa-rest-client/) I am encountering a problem with Basic HTTP Authentication (Authentication is failing). I have tested with Session Authentication and that works perfectly. My username and password are most certainly correct. The Services basic authentication module doesn't provide much in the way of setup, so what could I be doing wrong?
Modules being used:
Push Notifications
Services
Services basic authentication
REST Server
Drupal 7.22 minimal (vanilla install - no themes or any other fancy modules than the ones listed).
Basic auth enables you to GET, POST, PUT, and DELETE, to your endpoints using a Basic Auth Header. I am not sure if it will do anything for the /login end point. The authorization header should be made up of Basic followed by a based-64 encoded string of 'user:password' (not including the quotes).
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
You can quickly test this using Postman or Fiddler.
you need use the content access to restrict the access. This will require users to provide a login and password.
I found your article using Apache Auth with gitweb, gitosis.
I was wondering if there was a way to do this if I wasn't using LDAP for authentication. We currently have a very large NIS domain which we use for authentication on all unix servers.
We use this for SVN repositories through a UI, but for this case I am trying to meet a requirement of:
Git Repositories
Access Controlled - using Gitolite
Online UI - using Gitweb
UI must also have Access Control - not yet implemented
I was thinking first I need to get Gitweb and Gitolite to play together and each one works at the moment individually.
If gitolite provides access using SSH-keys, then it can provide the access this way by having a key for each machine a user/developer will be accessing Gitweb/gitolite from.
Or if I can get gitweb to simply authenticate users from NIS domain since every user has an account that our IT department sets up this would be better.
Any ideas or howtos I can use to get further on this requirement?
The way you link gitweb and gitosis together is by:
having gitweb configuration files with names identical to NIS logins
having gitweb.conf (from gitolite) including in gitweb_config.perl from this blog post (add at the end of gitweb_config.perl:)
use lib (".");
require "gitweb.conf";
using a NIS authentication for your Apache2 httpd.conf (or extra/httpd-ssl.conf if you are using https)
Once a user is authenticated (be it with basic, LDAP or NIS auth), the $cgi->remote_user will be set and that is that login which will be passed (by the gitolite gitweb.conf) to the gitolite perl script managing Git access rights (ACLs).
The Git ACLs are still managed by ssh key and are independent from the login mechanism, except for the login part which enable gitolite to make the right account association.