We are running a Rails application on Linux RedHat with a requirement
to validate users against a Windows NT Domain (single sign-on
scenario). Some sites use LDAP, others do not. Is there any Ruby
libraries or code samples that make this an easy thing to do? Anyone
have any recommendations on ways to get this implemented?
Thanks!
Windows NT domain? I dunno what libraries are available, but I'd
start with looking at samba. Also it may not be a ruby-level issue,
maybe it's something that can be setup on the web server side of
things? Just a thought.
On Mon, Jun 16, 2008 at 9:19 AM, ChessMess <chessmess@gmail.com> wrote:
We are running a Rails application on Linux RedHat with a requirement
to validate users against a Windows NT Domain (single sign-on
scenario). Some sites use LDAP, others do not. Is there any Ruby
libraries or code samples that make this an easy thing to do? Anyone
have any recommendations on ways to get this implemented?Thanks!
In our Apache config:
# Require authentication via LDAP
<Location "/">
AuthzLDAPAuthoritative off
AuthType Basic
AuthName "Restricted Area"
AuthBasicProvider ldap
AuthLDAPBindDN webapp@domain.local
AuthLDAPBindPassword cr@zypa55w0rd
AuthLDAPURL ldaps://server.domain.local:3269/dc=domain,dc=local?sAMAccountName?sub?(objectClass=*)
require valid-user
</Location>
... which is within a <VirtualHost> definition. You'll want to
replace some things (such as 'server' and 'domain') with things
specific to your configuration.
You can then retrieve the user name via
request.env['HTTP_REMOTE_USER'] in your Rails application.
On Jun 16, 10:19 am, ChessMess <chessm...@gmail.com> wrote:
We are running a Rails application on Linux RedHat with a requirement
to validate users against a Windows NT Domain (single sign-on
scenario). Some sites use LDAP, others do not. Is there any Ruby
libraries or code samples that make this an easy thing to do? Anyone
have any recommendations on ways to get this implemented?Thanks!
I am able to do this at the work-place using ruby net/ldap library. If
LDAP bind succeeds, one is authenticated user...
Hope this helps,
Vlad
PS: The net/ldap can also do this over SSL...
Vladimir,
I don't know what his actual situation is, but back in the bad old
NT4 domain days, there was no LDAP part of it at all. I know, we're
still using an NT4 domain at work.
--Kyle
On Tue, Jun 17, 2008 at 1:53 PM, Vladimir Konrad <vk@dsl.pipex.com> wrote:
I am able to do this at the work-place using ruby net/ldap library. If
LDAP bind succeeds, one is authenticated user...Hope this helps,
Vlad
PS: The net/ldap can also do this over SSL...
I don't know what his actual situation is, but back in the bad old
NT4 domain days, there was no LDAP part of it at all. I know, we're
still using an NT4 domain at work.
Aha, well, I do not know much about NT4 domains (or AD), but I thought
that AD always had LDAP compatibility...
More info would help...
Vlad
PS: If ChessMess posts more info, I can post, if relevant, working code
(it is for ramaze, but it is a start).
You're right, AD is basically LDAP+Kerberos and a whole lotta
microsoft anti-standards, but NT4 and earlier didn't use any of that.
It was just it's own thing.
On Wed, Jun 18, 2008 at 1:58 PM, Vladimir Konrad <vk@dsl.pipex.com> wrote:
I don't know what his actual situation is, but back in the bad old
NT4 domain days, there was no LDAP part of it at all. I know, we're
still using an NT4 domain at work.Aha, well, I do not know much about NT4 domains (or AD), but I thought
that AD always had LDAP compatibility...
Hey guys,
I have some more info as to what we're trying to accomplish.
I recently came across the ruby-ntlm gem and installed it. Then, I
took a look at the example smtp.rb which uses NTLM to authenticate
against a SMTP server (running on IIS that's connected to a NT4
domain) and it works great. However, I've not been able to figure out
how we could pass the actual domain name without relying on the domain
of the SMTP server for which we're authenticating against.
For example...
User1 is on Domain1. User1 logs into our app with their username/
password that's defined on Domain1 and get successfully authenticated.
User2 is on Domain2. User2 logs into our app (using the same SMTP host
- remember, this SMTP server is joined to Domain1) and is unsuccessful
at authenticating.
Ultimately, we would like to be able to pass "Domain2\User2" as the
username and have the ruby-ntlm gem authenticate this user.
Another colleague and I have dove into the ntlm.rb (ruby-ntlm's main
file) via the debugger and it seems to only be getting the domain from
the SMTP host which is being used for the authentication.
In essence, does anybody know how to pass the domain of the user being
authenticated to ruby-ntml so we can have our multi-trusted domain
users authenticate against a single SMTP server?
Thanks!
Kyle Schmitt wrote:
I don't know what his actual situation is, but back in the bad old
NT4 domain days, there was no LDAP part of it at all. I know, we're
still using an NT4 domain at work.Aha, well, I do not know much about NT4 domains (or AD),
NT4 authenticates using NTLM, a fairly straight-forward password-based
challenge-authentication mechanism.
but I thought that AD always had LDAP compatibility...
You're right, AD is basically LDAP+Kerberos and a whole lotta
microsoft anti-standards,
You're quite wrong to bash MS over this. It's true they made
one small extension to the Kerberos standard and didn't publish
it until after they got bashed up about it, but the actual
change they made corrected a deficiency in the Kerberos standard
itself, by providing a list of group memberships in the TGT
(Ticket Granting Ticket, the result of the AP, Authentication
Protocol). The "tokenGroups" attribute gets propagated to the
service tickets issued in later exchanges,
Without group memberships in the tickets, every service must keep
a separate access rights (authorization) database with an entry
for every user, or refer back to the Kerberos server whenever any
authorization question must be decided. Both alternatives are
fundamentally at odds with the original design goals of Kerberos
itself, and is a serious flaw in its design.
The structure of the tokenGroups (a list of SIDs) isn't what an
open process would have designed (names would have been used
instead of numbers), but it was pragmatic, and being relevant
only to the NT4 security model, they thought it wasn't necessary
to publish it. Had the standard not had this deficiency, I'm
confident MS would have used it without change.
MS' decision to use Kerberos was actually the right thing to do
and has definitely helped the cause of Kerberos and of greater
IT security. It reflects a move away from their earlier policy
of always using solutions they own (either by making or acquiring).
I can believe MS guilty of much of the evil of which they're
accused, but I think this one at least was an honest mistake.
Clifford Heath.
On Wed, Jun 18, 2008 at 1:58 PM, Vladimir Konrad <vk@dsl.pipex.com> wrote:
Humm, I've never thought about it in that respect before. But
wouldn't the more appropriate thing be to have group memberships and
service rights stored in the LDAP portion, and only use Kerberos for
the authentication?
--Kyle
On Wed, Jun 18, 2008 at 6:38 PM, Clifford Heath <no@spam.please.net> wrote:
You're quite wrong to bash MS over this. It's true they made
one small extension to the Kerberos standard and didn't publish
it until after they got bashed up about it, but the actual
change they made corrected a deficiency in the Kerberos standard
itself, by providing a list of group memberships in the TGT
(Ticket Granting Ticket, the result of the AP, Authentication
Protocol). The "tokenGroups" attribute gets propagated to the
service tickets issued in later exchanges,Without group memberships in the tickets, every service must keep
a separate access rights (authorization) database with an entry
for every user, or refer back to the Kerberos server whenever any
authorization question must be decided. Both alternatives are
fundamentally at odds with the original design goals of Kerberos
itself, and is a serious flaw in its design.
Kyle Schmitt wrote:
Without group memberships in the tickets, every service must keep
a separate access rights (authorization) database with an entry
for every user, or refer back to the Kerberos server whenever any
authorization question must be decided.
Humm, I've never thought about it in that respect before. But
wouldn't the more appropriate thing be to have group memberships and
service rights stored in the LDAP portion, and only use Kerberos for
the authentication?
That requires my 2nd alternative, for each service to check group membership
by calling the LDAP server at every authorisation decision point. It's
hugely costly, and defeats the advantages of using a ticketing system in
the first place.
What AD does is to merge the LDAP and Kerberos services into one system,
which is smart since they really are tightly coupled. The group m'ships
in the tickets are fetched by Kerberos from the LDAP part during domain
logon. That itself is a very costly operation, since it involves calls
to other domains in the same domain tree, where relevant group membership
info may be stored. You definitely don't want this being done at every
decision point!
Clifford Heath.
On Wed, Jun 18, 2008 at 6:38 PM, Clifford Heath <no@spam.please.net> wrote: