<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16525" name=GENERATOR></HEAD>
<BODY><!-- Converted from text/plain format -->
<P><FONT size=2>Scott:<BR><BR>Thanks for the link and the information.
Clearly, from the links I found under the search you sent, public keys are more
secure than passwords. This is also true for non-kerberized SSH
environments.<BR><BR>Of course, the weakness in password authentication schemes
applies mostly to weak passwords and Windoze does allow you to specify an
arbitrarily complex password scheme. The O'Reilly book, <U>Practical Unix
and Internet Security</U>, has a great chapter on strong vs.. weak
passwords. System administrators who rely on password-based
authentications schemes MUST enforce strong passwords, password aging,
etc.<BR><BR>At our site, the reason that we felt turning off forwardable tickets
was not an option is that our users frequently need to connect from Unix machine
A to Unix machine B. If forwardable tickets are turned off, then a user
connecting from A to B directly must use a protocol such as SSH, which (although
encrypted) does put the password on the wire, and thus is vulnerable to the
rainbow table attack. Worse still, if any unencrypted protocols
(ftp, telnet, rlogin, etc.) are left open on even a single system, you will now
have AD passwords on the wire in cleartext.</FONT></P>
<P><FONT size=2>Of course, you can enforce a "no insecure protocols"
policy, enforcing ssh, scp and sftp over telnet, rsh, rcp and ftp.
You could also set your users up with ssh keys and disable ssh password
authentication. But, at that point, it does not appear that you have
gained much of anything over and above what you would get from a pure ssh
authentication policy, without AD authentication in the picture.</FONT></P>
<P><FONT size=2>What do you think?</FONT></P>
<P><FONT size=2>Regards,</FONT></P>
<P><FONT size=2>Josh</FONT></P>
<P><FONT size=2>P.S. I see you work across the street, at MIT. Care to do
lunch sometime?</FONT><BR><BR><FONT size=2>-----Original Message-----<BR>From:
Sean OMeara [</FONT><A href="mailto:someara@gmail.com"><FONT
size=2>mailto:someara@gmail.com</FONT></A><FONT size=2>]<BR>Sent: Friday, August
24, 2007 7:42 AM<BR>To: Joshua Putnam<BR>Cc: Scott Ehrlich;
bblisa@bblisa.org<BR>Subject: Re: [BBLISA] Single sign-on help
requested<BR><BR>What I meant by "sniffed kerberos passwords" was "sniffed
kerberos exchanges"<BR>You can still run an offline dict/brute force on
it.<BR><BR></FONT><A
href="http://www.google.com/search?hl=en&q=kerberos+%22looks+like+a+timestamp%22&btnG=Search"><FONT
size=2>http://www.google.com/search?hl=en&q=kerberos+%22looks+like+a+timestamp%22&btnG=Search</FONT></A><BR><BR><FONT
size=2>turning off forwardable tickets is annoying only if you've every been
used to having them! %99.99r users wont notice or care that they're
off.<BR><BR>And yes, winbind is the devil. =)<BR><BR>-s<BR><BR>On 8/23/07,
Joshua Putnam <Joshua.Putnam@intersystems.com> wrote:<BR>> I'm not sure
what you mean by "sniffed kerberos passwords." Kerberos<BR>> never
places any passwords on the wire, encrypted or not, so how would<BR>> you
sniff them?<BR>><BR>> I've done extensive testing of both home-rolled AD
authentication to<BR>> Unix and Commercial products (Centrify, Vintela
Authentication<BR>> Services, aka. VAS). The home-rolled solutions are
cumbersome to<BR>> implement and require patches/changes to system libraries,
which may<BR>> not be a problem in production environments but is
unacceptable in<BR>> most development environments. Home rolled
solutions, depending on<BR>> pam_nss, are also not available for some older
Unix platforms.<BR>><BR>> The biggest gotcha is the vulnerability of
forwardable Kerberos<BR>> tickets to theft by any user with root
priviledges. If a user has<BR>> root, they can steal any other user's
ticket cache from /tmp or the<BR>> user's homedir on a Unix system and use it
to impersonate that user<BR>> anywhere else on the network. But with
forwardable tickets disabled<BR>> (from the AD domain controller),
single-sign on will only work from a<BR>> Windows client to the first Unix
box. A user will not be able to then<BR>> single-sign on to a second
Unix box from there.<BR>><BR>> SAMBA/Winbind also has significant
limitations on the assignment of<BR>> consistent UIDs on multiple Unix/Linux
hosts.<BR>><BR>> Of course, you could audit the Unix boxes with
forwardable tickets<BR>> from another, secure system, to see if anyone is
abusing the tickets.<BR>><BR>> :)<BR>><BR>> Joshua Putnam<BR>>
Sr. Unix Administrator<BR>> Intersystems Corporation<BR>> 1 Memorial
Drive<BR>> Cambridge, MA 02142<BR>><BR>><BR>><BR>><BR>>
-----Original Message-----<BR>> From: bblisa-bounces@bblisa.org [</FONT><A
href="mailto:bblisa-bounces@bblisa.org"><FONT
size=2>mailto:bblisa-bounces@bblisa.org</FONT></A><FONT size=2>] On<BR>>
Behalf Of Sean OMeara<BR>> Sent: Thursday, August 23, 2007 10:09 AM<BR>>
To: Scott Ehrlich<BR>> Cc: bblisa@bblisa.org<BR>> Subject: Re: [BBLISA]
Single sign-on help requested<BR>><BR>> Also the use of NTLM makes sniffed
passwords extremly easy to crack<BR>> using rainbow tables<BR>><BR>>
</FONT><A href="http://www.antsight.com/zsl/rainbowcrack/"><FONT
size=2>http://www.antsight.com/zsl/rainbowcrack/</FONT></A><BR><FONT
size=2>><BR>> sniffed kerberos passwords are still vulnerable to an
offline<BR>> dictionary/brute force attack, but you you cant use the
neato<BR>> time/space tradeoff like you can on ntlm<BR>><BR>><BR>>
On 8/23/07, Sean OMeara <someara@gmail.com> wrote:<BR>> > To
paraphrase my previous post:<BR>> ><BR>> > 1) It's not true single
sign on, only unified passwords<BR>> ><BR>> > 2) the passwords will
fall out of sync between the windows and linux<BR>> > side unless they're
changed from windows<BR>> ><BR>> ><BR>> > On 8/23/07, Scott
Ehrlich <scott@mit.edu> wrote:<BR>> > > Sorry to top-post, but it
is my intention to use samba on the RH 5<BR>> > > box to act as my
domain controller. I thought I read somewhere<BR>> > >
that<BR>><BR>> > > accounts<BR>> > > (user/pass) can be
easily synced ldap and samba, including home<BR>> > > dirs? Am I
wrong?<BR>> > ><BR>> > > Thanks.<BR>> > ><BR>>
> > Scott<BR>> > ><BR>> > > On Thu, 23 Aug 2007, Sean
OMeara wrote:<BR>> > ><BR>> > > > Scott:<BR>> > >
><BR>> > > > If you want TRUE single sign on capabilities and you
intend to<BR>> > > > involve Windows in any way, you absolutely have
to use an Active<BR>> > > > Directory as your kerberos KDC. There is
ABSOLUTELY NO WAY<BR>> > > > around it. (unless of course you're
adventurous enough to use<BR>> > > > samba4)<BR>> > >
><BR>> > > > By TRUE sigle sign on I mean:<BR>> > > >
passwordless authentication to network resources (ssh, samba<BR>> > >
> shares/<BR>> > > > NFSv4 servers, (homedirs!)
apache/mod_spnego, jabber/sasl,<BR>> > > > ssh/gssapi, ldap/sasl,
AFS, the works) from both the XP clients<BR>> > > > and the
linux/unix clients.<BR>> > > ><BR>> > > > The only way
to do it is:<BR>> > > > authentication<BR>> > > >
*Active Directory KDC + LDAP + RPC for windows<BR>> > > >
authentication/authorization *Active Directory KDC for unixland<BR>> >
> > kerberos authentication<BR>> > > ><BR>> > > >
authorization<BR>> > > > * Active Directory ldap server schema
extensions (ms SFUv3.5) to<BR>> > > > house the unix posix data
(uid, gid, homedir, shell,<BR>> > > > supplemental gids<BR>> >
> > ((/etc/group))<BR>> > > ><BR>> > > >
or<BR>> > > > * seperate ldap resource (openldap, fedoraDS)
dedicated to<BR>> > > > housing<BR>><BR>> > > > the
unix posix data<BR>> > > > * scripting fun to keep your groups in
order<BR>> > > ><BR>> > > > The reason for this lies in
the way Windows handles the<BR>> > > > authorization part of the
sign on process. ( unix clients dig<BR>> > > > their authorization
data out of ldap, windows clients have it<BR>> > > > returned in the
PAC field within their kerberos ticket)<BR>> > > ><BR>> > >
> It's actually not that bad really.... AD can be manipulated from<BR>>
> > > the linux command line via samba tools (net ads user add,
net<BR>> > > > ads group delete, etc)<BR>> > > ><BR>>
> > > ......<BR>> > > ><BR>> > > > now barring
all that... if what you meant by "single sign on" is<BR>> > > >
actually "unified passwords", then you can do it without AD<BR>> > >
> using samba and ldap no problem. (well, only small problems<BR>> >
> > anyway)<BR>> > > ><BR>> > > ><BR>> >
> > No matter what you'll have to maintain TWO password databases,<BR>>
> > > one<BR>><BR>> > > > for windows, and one for
everyone else.<BR>> > > ><BR>> > > > The standard
configuration for this is one of the two of these:<BR>> > >
><BR>> > > > a)<BR>> > > > authentication<BR>>
> > > * Windows NT4 style NTLMv2 Samba v3 authentication<BR>> >
> > * Samba looks at an ldap backend for:<BR>> > > >
sambaLMPassword:<BR>> > > > sambaNTPassword:<BR>> > >
><BR>> > > > * unixland clients attempt a bind to the ldap
server, testing<BR>> against the field:<BR>> > > >
userPassword<BR>> > > ><BR>> > > >
authorization:<BR>> > > > Samba looks at an ldap backend for, and
then returns to the<BR>> > > > windows machine via rpc:<BR>> >
> > sambaAcctFlags<BR>> > > > sambaPrimaryGroupSID:<BR>>
> > > sambaLogonTime:<BR>> > > >
sambaPasswordHistory<BR>> > > > sambaSID<BR>> > > >
sambaPwdCanChange:<BR>> > > > sambaAcctFlags:<BR>> > > >
sambaPwdLastSet:<BR>> > > > sambaPwdMustChange<BR>> > >
><BR>> > > > b)<BR>> > > > authentication:<BR>>
> > > samba stuff for windows<BR>> > > > unixland looks to
an MIT or Heimdal KDC for authentication<BR>> > > ><BR>> >
> > authorization:<BR>> > > > same stuff for windows<BR>>
> > > unixland looks in the ldap directory for:<BR>> > > >
uidNumber<BR>> > > > gidNumber<BR>> > > >
homeDirectory<BR>> > > > groups information<BR>> > >
><BR>> > > > The consequences of the dual password sources will
boil down to<BR>> this:<BR>> > > ><BR>> > > > When a
user changes his password via the unix passwd utility, it<BR>> > > >
will only change:<BR>> > > > the userPassword field in the ldap
record or the password on the<BR>> > > > kerberos principal.<BR>>
> > ><BR>> > > > Windows users change it via samba, which
can call a script to<BR>> > > > change both the sambaNTPassword
fields and the userPassword<BR>> > > > fields<BR>><BR>> >
> > in the ldap record.<BR>> > > ><BR>> > > > I'm
not sure if its possible to have samba call a script to set<BR>> > >
> the sambaNTPassword and change the kerberos princ.<BR>> > >
><BR>> > > > PS if you're going to get kerberos involved in any
way, every<BR>> > > > machine needs to be able to resolve their
FQDN, both forward and<BR>> > > > reverse. This means you either
need to maintain lots of<BR>> > > > /etc/hosts<BR>><BR>> >
> > entries in the<BR>> > > > form:<BR>> > >
><BR>> > > > 127.0.0.1
localhost
localhost.localdomain<BR>> > > >
127.0.0.1 somebox.mit.edu
sombox<BR>> > > ><BR>> > > > or proper 1 to 1 mapped
forward and reverse DNS.<BR>> > > ><BR>> > > > If your
machine can't correctly do hostname and hostname -f,<BR>> > > >
kerberos will NOT WORK.<BR>> > > ><BR>> > > >
.....<BR>> > > ><BR>> > > > To answer your questions
about the homedirs:<BR>> > > ><BR>> > > > You want a
fileserver running both samba and NFS.<BR>> > > > Windows clients
will use roaming profiles to mount their<BR>> > > > homedirs via
SMB, linux will use NFS.<BR>> > > ><BR>> > > > Your
error messages look like your ldap server isnt running.<BR>> > >
><BR>> > > > -s<BR>> > > ><BR>> > >
><BR>> > > ><BR>> > > > PS I live around the corner
from MIT and I'm much better at<BR>> > > > explaining things when
people buy me ronnie burgers ;)<BR>> > > ><BR>> > > >
-s<BR>> > > ><BR>> > > ><BR>> > > > On
8/23/07, Scott Ehrlich <scott@mit.edu> wrote:<BR>> > > >> I
have a RHEL5 Server and some dual-boot XP/CentOS 5 systems<BR>> (Linux
systems all<BR>> > > >> 64-bit). All Linux is
out-of-box, with all packages, minus<BR>> international<BR>> > >
>> languages, installed. No patching has been done.<BR>> >
> >><BR>> > > >> On the server, I selected
system-config-authentication and<BR>> > > >> enabled LDAP for
User Information, Kerberos, LDAP, and SMB for<BR>> > > >>
Authentication, and Shadow and<BR>> > > >> MD5 Passwords, along
with Authenticate system accounts by<BR>> > > >>
network<BR>><BR>> > > >> services for Options.<BR>> >
> >><BR>> > > >> All machines are on an isolated LAN,
with no DNS server (I<BR>> > > >> could always enable and
configure DNS on the server if it helps<BR>> > > >> the<BR>>
cause).<BR>> > > >><BR>> > > >> I also don't know
if it matters, but the server is running the<BR>> > > >>
virtualization kernel (xen), but the clients are not.<BR>> > >
>><BR>> > > >> I only have LDAP service enabled on the
server. Kerberos<BR>> services are enabled<BR>> > >
>> on both client and server.<BR>> > > >><BR>> > >
>> I tweaked the LDAP and Kerberos settings using the CentOS/RH<BR>>
> > >> GUIs, and have the clients looking to the RH box for<BR>>
authentication.<BR>> > > >><BR>> > > >> I also
have the firewall enabled, but am letting kerberos and<BR>> > >
>> ldap ports through as tcp.<BR>> > > >><BR>> > >
>> During a login test, /var/log/messages on the client showed:<BR>>
> > >><BR>> > > >> lin1 gdm[pid]: nss_ldap: failed to
bind to LDAP server<BR>> ldap://192.168.1.100:<BR>> > > >>
Can't contact LDAP server<BR>> > > >><BR>> > > >>
lin1 gdm[pid]: nss_ldap: reconnecting to LDAP server (sleeping<BR>> > >
>> 32<BR>> seconds)...<BR>> > > >><BR>> > >
>> lin1 dbus-daemon: nss_ldap: failed to bind to LDAP server<BR>>
ldap://192.168.1.100:<BR>> > > >> Can't contact LDAP
server<BR>> > > >><BR>> > > >> lin1 dbus-daemon:
dss_ldap: failed to bind to LDAP server...<BR>> > > >><BR>>
> > >> lin1 xfs: ...<BR>> > > >><BR>> > >
>><BR>> > > >> During boot time, Starting system message
bus: [long pause]<BR>> > > >> then error messages about DB_CONFIG
and /var/lib/ldap, the<BR>> > > >> usual cannot find DB_CONFIG in
/var/lib/ldap, showing the<BR>> > > >> example.com instead of my
customized ldap settings, etc.<BR>> > > >><BR>> > >
>> I've checked openldap.org, but I figured if the configuration<BR>>
> > >> appears to be simplified via an included GUI, I shouldn't
have<BR>> > > >> much trouble gettigns things going.<BR>> >
> >><BR>> > > >> Anyway, what am I missing?
Anything special RH 5 is doing<BR>> compared to the<BR>> > >
>> openldap docs?<BR>> > > >><BR>> > > >>
Both servers have been rebooted since adding the respective<BR>> > >
>> ports<BR>><BR>> > > >> in the firewall.<BR>> >
> >><BR>> > > >> The goal is a to permit my test user,
created on the server, to<BR>> > > >> sit at a workstation, boot
into either Linux or XP, and get<BR>> > > >> their<BR>> home
directory.<BR>> > > >><BR>> > > >> Ideally, the
server only needs to consist of one account for<BR>> > > >> them,
which they get upon login on the workstation.<BR>> > > >><BR>>
> > >> I want to highly restrict _any_ third-party
tools/apps/etc. I<BR>> will be happy<BR>> > > >>
to take suggestions and leads, but I want to try and rely on<BR>> > >
>> what<BR>><BR>> > > >> RH has provided.<BR>> >
> >><BR>> > > >> Thanks for any insight/help.<BR>>
> > >><BR>> > > >> Scott<BR>> > >
>><BR>> > > >>
_______________________________________________<BR>> > > >>
bblisa mailing list<BR>> > > >> bblisa@bblisa.org<BR>> >
> >> </FONT><A
href="http://www.bblisa.org/mailman/listinfo/bblisa"><FONT
size=2>http://www.bblisa.org/mailman/listinfo/bblisa</FONT></A><BR><FONT
size=2>> > > >><BR>> > > ><BR>> > ><BR>>
><BR>><BR>> _______________________________________________<BR>>
bblisa mailing list<BR>> bblisa@bblisa.org<BR>> </FONT><A
href="http://www.bblisa.org/mailman/listinfo/bblisa"><FONT
size=2>http://www.bblisa.org/mailman/listinfo/bblisa</FONT></A><BR><FONT
size=2>><BR></P></FONT></BODY></HTML>