GSSAPI and Kerberos - understanding question

[Josh Geisser]

Hi list

I'm sure I have gabs of understanding of how to use SSSD without using plain binding-user credentials in the configfile. I followed the guide for Win2008 allthough I only have 2003 SFU - would that work?

- I see it right that GSSAPI should enable looking up stuff in the LDAP using a machine-account instead of the binding-user/passwd?

- Kerberos (which has the machine-auth-ticket) comes into play for LDAP, but this exceeds the basic LDAP authentication (eg. Auth via Kerberos on the LDAP server)?  Is this enough to feed nsswitch (e.g. getent) or is an  additional valid user/pass still required?

The trouble I'm having here is the ktpasswd.exe generated-key is always dated at 01/01/70 01:00:00 which I guess is also the reason why ldapsearch -Y GSSAPI and kinit fail? 2003 behaviour?

The krb and ldap configuration works quite fine with bind-dn, just struggeling with SASL/GSSAPI.

Cheers
Josh

[John Hodrien]

On Wed, 23 Nov 2011, Josh Geisser wrote:
> Hi list
>
> I'm sure I have gabs of understanding of how to use SSSD without using plain
> binding-user credentials in the configfile. I followed the guide for Win2008
> allthough I only have 2003 SFU - would that work?

AFAIK, yes.  I've certainly contributed that with 2003 in mind.
> I see it right that GSSAPI should enable looking up stuff in the LDAP
>
> using a machine-account instead of the binding-user/passwd?

Yes.  I think that's the best way to do it.
> Kerberos (which has the machine-auth-ticket) comes into play for LDAP, but
>
> this exceeds the basic LDAP authentication (eg. Auth via Kerberos on the
> LDAP server)?  Is this enough to feed nsswitch (e.g. getent) or is an
> additional valid user/pass still required?

I'm not sure I follow.  You don't need anything other than the valid keytab.
> The trouble I'm having here is the ktpasswd.exe generated-key is always
> dated at 01/01/70 01:00:00 which I guess is also the reason why ldapsearch
> -Y GSSAPI and kinit fail? 2003 behaviour?

Personally I'd not use ktpasswd and follow the "Creating Service Keytab with
Samba" section.  All in I'd say that's much easier when you're dealing with
lots of machines, and it doesn't require Domain Administrator rights.  You need
samba installed (anything >3.0 should work fine with 2003 AFAIK) and a correct
smb.conf (and krb5.conf).  I /think/ this would be sufficient:

[global]

workgroup = YOURDOMAIN
    client signing = yes
    client use spnego = yes
    kerberos method = secrets and keytab
    password server = your.kdc.net
    realm = YOURFULLKERBEROSDOMAIN
    security = ads
> The krb and ldap configuration works quite fine with bind-dn, just
> struggeling with SASL/GSSAPI.

Just us know how you get get on,

jh

[Josh Geisser]

Thanks for the answer will check soon.

Joining the machine actually works as far as I understand: it creates the computer object in LDAP and is visible in the AD management utility.

But it doesn't write any local /etc/krb5.keytab, which I assume SSSD or the krb5-tools will use, not?

Want to try your additional smb.conf parameters and I'll come back to you

Thanks a lot so far

Cheers
Josh

-----Ursprüngliche Nachricht-----
Von: [e-mail] [mailto:[e-mail]] Im Auftrag von John Hodrien
Gesendet: Mittwoch, 23. November 2011 22:30
An: Development of the System Security Services Daemon
Betreff: Re: [SSSD] GSSAPI and Kerberos - understanding question

On Wed, 23 Nov 2011, Josh Geisser wrote:
> Hi list
>
> I'm sure I have gabs of understanding of how to use SSSD without using plain
> binding-user credentials in the configfile. I followed the guide for Win2008
> allthough I only have 2003 SFU - would that work?

AFAIK, yes.  I've certainly contributed that with 2003 in mind.
> I see it right that GSSAPI should enable looking up stuff in the LDAP
>
> using a machine-account instead of the binding-user/passwd?

Yes.  I think that's the best way to do it.
> Kerberos (which has the machine-auth-ticket) comes into play for LDAP, but
>
> this exceeds the basic LDAP authentication (eg. Auth via Kerberos on the
> LDAP server)?  Is this enough to feed nsswitch (e.g. getent) or is an
> additional valid user/pass still required?

I'm not sure I follow.  You don't need anything other than the valid keytab.
> The trouble I'm having here is the ktpasswd.exe generated-key is always
> dated at 01/01/70 01:00:00 which I guess is also the reason why ldapsearch
> -Y GSSAPI and kinit fail? 2003 behaviour?

Personally I'd not use ktpasswd and follow the "Creating Service Keytab with
Samba" section.  All in I'd say that's much easier when you're dealing with
lots of machines, and it doesn't require Domain Administrator rights.  You need
samba installed (anything >3.0 should work fine with 2003 AFAIK) and a correct
smb.conf (and krb5.conf).  I /think/ this would be sufficient:

[global]

workgroup = YOURDOMAIN
    client signing = yes
    client use spnego = yes
    kerberos method = secrets and keytab
    password server = your.kdc.net
    realm = YOURFULLKERBEROSDOMAIN
    security = ads
> The krb and ldap configuration works quite fine with bind-dn, just
> struggeling with SASL/GSSAPI.

Just us know how you get get on,

jh
_______________________________________________
sssd-devel mailing list
[e-mail]
https://fedorahosted.org/mailman/listinfo/sssd-devel

[John Hodrien]

On Wed, 23 Nov 2011, Josh Geisser wrote:
> Thanks for the answer will check soon.
>
> Joining the machine actually works as far as I understand: it creates the
> computer object in LDAP and is visible in the AD management utility.
>
> But it doesn't write any local /etc/krb5.keytab, which I assume SSSD or the
> krb5-tools will use, not?
>
> Want to try your additional smb.conf parameters and I'll come back to you

Will update the article with some more notes on this tomorrow.  My config was
for samba 3.5, I don't know what version you're running.  You definitely need
the keytab line in your config (that line is different in 3.0 but you'll find
it in the man page).

Once you've done that, join the domain again, and /etc/krb5.keytab should be
created, and yes, that's what sssd uses.

jh

[Josh Geisser]

Adding your tip to the smb.conf did the trick.
[global]
        client signing = mandatory
        client use spnego = yes
        kerberos method = secrets and keytab

net join ads  and the keytab is written and can be used by sssd. Also the timestamps are from now and not the 70ties. So seems to work with 2003 SFU.

Perfect & thanks a lot :)
You might add "klist -kte" and "net ads status/info" also to the documentation as they help a lot verifying what's happening.

Sorry question anyway: using the keytab just eases the issue with plaintext binding credentials, but is actually still an 'weakness': stealing this key enables you to the active-directory from anywhere, anyway, not?

Is there a scenario where the 'challenging' username/passwd is taken to authenticate against the AD? E.g. the credentials I just ssh/pam-entered are used against LDAP instead of any pre-configured credentials?

Cheers
Josh

-----Ursprüngliche Nachricht-----
Von: [e-mail] [mailto:[e-mail]] Im Auftrag von John Hodrien
Gesendet: Mittwoch, 23. November 2011 23:33
An: Development of the System Security Services Daemon
Betreff: Re: [SSSD] GSSAPI and Kerberos - understanding question

On Wed, 23 Nov 2011, Josh Geisser wrote:
> Thanks for the answer will check soon.
>
> Joining the machine actually works as far as I understand: it creates the
> computer object in LDAP and is visible in the AD management utility.
>
> But it doesn't write any local /etc/krb5.keytab, which I assume SSSD or the
> krb5-tools will use, not?
>
> Want to try your additional smb.conf parameters and I'll come back to you

Will update the article with some more notes on this tomorrow.  My config was
for samba 3.5, I don't know what version you're running.  You definitely need
the keytab line in your config (that line is different in 3.0 but you'll find
it in the man page).

Once you've done that, join the domain again, and /etc/krb5.keytab should be
created, and yes, that's what sssd uses.

jh
_______________________________________________
sssd-devel mailing list
[e-mail]
https://fedorahosted.org/mailman/listinfo/sssd-devel

[Josh Geisser]

Sorry was a bit too fast in replying: first you already documented the verification steps (sorry), second I broke it again :)

And I'm back in a state of confusion: 
If the keytab is written and krb5.conf is good, I should be able to verify this with "kinit", not?

I re-setup that machine and wanted to rejoin it, so I removed it from the AD via Users&Computer and a dead-body entry from the LDAP (CN=pontus,CN=Computers,DC=example,DC=com).

Then I did a  net ads join  which succeeded with keytab generated:
# klist -kte
Keytab name: WRFILE:/etc/krb5.keytab
KVNO Timestamp         Principal
---- ----------------- -----------------------------------------------------
   2 11/24/11 23:48:24 host/[e-mail] (des-cbc-crc)
   2 11/24/11 23:48:25 host/[e-mail] (des-cbc-md5)
   2 11/24/11 23:48:25 host/[e-mail] (arcfour-hmac)
   2 11/24/11 23:48:25 host/[e-mail] (des-cbc-crc)
   2 11/24/11 23:48:25 host/[e-mail] (des-cbc-md5)
   2 11/24/11 23:48:25 host/[e-mail] (arcfour-hmac)
   2 11/24/11 23:48:25 PONTUS$@EXAMPLE.COM (des-cbc-crc)
   2 11/24/11 23:48:25 PONTUS$@EXAMPLE.COM (des-cbc-md5)
   2 11/24/11 23:48:25 PONTUS$@EXAMPLE.COM (arcfour-hmac)

But using this ticket now fails, in sssd and also with kinit, both with 'cred. not found':

# kinit -V -k -t /etc/krb5.keytab host/[e-mail]
Using default cache: /tmp/krb5cc_0
Using principal: host/[e-mail]
Using keytab: /etc/krb5.keytab
kinit: Client 'host/[e-mail]' not found in Kerberos database while getting initial credentials

SSSD: (Thu Nov 24 23:54:03 2011) [[sssd[ldap_child[931]]]] [ldap_child_get_tgt_sync] (0): Failed to init credentials: Client 'host/[e-mail]' not found in Kerberos database

Principal is listed in "klist", but not found by "kinit"? What did I do wrong this time?

I'm both times using FC16/x64 netinstall (sssd-1.6.3, smb-3.6.1 & krb5-workstation-1.9.1), restored smb.conf, krb5.conf and of coarse sssd.conf (which seems to be missing by basic minimal fc16 install?)
I assume krb5.conf is right since "kinit myuser" succeeds, only fails when using the keytab.

Cheers
Josh

-----Ursprüngliche Nachricht-----
Von: [e-mail] [mailto:[e-mail]] Im Auftrag von Josh Geisser
Gesendet: Donnerstag, 24. November 2011 18:26
An: Development of the System Security Services Daemon
Betreff: Re: [SSSD] GSSAPI and Kerberos - understanding question

Adding your tip to the smb.conf did the trick.
[global]
        client signing = mandatory
        client use spnego = yes
        kerberos method = secrets and keytab

net join ads  and the keytab is written and can be used by sssd. Also the timestamps are from now and not the 70ties. So seems to work with 2003 SFU.

Perfect & thanks a lot :)
You might add "klist -kte" and "net ads status/info" also to the documentation as they help a lot verifying what's happening.

Sorry question anyway: using the keytab just eases the issue with plaintext binding credentials, but is actually still an 'weakness': stealing this key enables you to the active-directory from anywhere, anyway, not?

Is there a scenario where the 'challenging' username/passwd is taken to authenticate against the AD? E.g. the credentials I just ssh/pam-entered are used against LDAP instead of any pre-configured credentials?

Cheers
Josh

-----Ursprüngliche Nachricht-----
Von: [e-mail] [mailto:[e-mail]] Im Auftrag von John Hodrien
Gesendet: Mittwoch, 23. November 2011 23:33
An: Development of the System Security Services Daemon
Betreff: Re: [SSSD] GSSAPI and Kerberos - understanding question

On Wed, 23 Nov 2011, Josh Geisser wrote:
> Thanks for the answer will check soon.
>
> Joining the machine actually works as far as I understand: it creates the
> computer object in LDAP and is visible in the AD management utility.
>
> But it doesn't write any local /etc/krb5.keytab, which I assume SSSD or the
> krb5-tools will use, not?
>
> Want to try your additional smb.conf parameters and I'll come back to you

Will update the article with some more notes on this tomorrow.  My config was
for samba 3.5, I don't know what version you're running.  You definitely need
the keytab line in your config (that line is different in 3.0 but you'll find
it in the man page).

Once you've done that, join the domain again, and /etc/krb5.keytab should be
created, and yes, that's what sssd uses.

jh
_______________________________________________
sssd-devel mailing list
[e-mail]
https://fedorahosted.org/mailman/listinfo/sssd-devel

[John Hodrien]

On Thu, 24 Nov 2011, Josh Geisser wrote:
> Sorry was a bit too fast in replying: first you already documented the
> verification steps (sorry), second I broke it again :)
>
> And I'm back in a state of confusion: 
> If the keytab is written and krb5.conf is good, I should be able to verify
> this with "kinit", not?

Yes.
> I re-setup that machine and wanted to rejoin it, so I removed it from the AD
> via Users&Computer and a dead-body entry from the LDAP
> (CN=pontus,CN=Computers,DC=example,DC=com).

You can also do "net ads leave" from the machine itself.
> Then I did a  net ads join  which succeeded with keytab generated:
> # klist -kte
> Keytab name: WRFILE:/etc/krb5.keytab
> KVNO Timestamp         Principal
>
> 2 11/24/11 23:48:24 host/[e-mail] (des-cbc-crc)
>   2 11/24/11 23:48:25 host/[e-mail] (des-cbc-md5)
>   2 11/24/11 23:48:25 host/[e-mail] (arcfour-hmac)
>   2 11/24/11 23:48:25 host/[e-mail] (des-cbc-crc)
>   2 11/24/11 23:48:25 host/[e-mail] (des-cbc-md5)
>   2 11/24/11 23:48:25 host/[e-mail] (arcfour-hmac)
>   2 11/24/11 23:48:25 PONTUS$@EXAMPLE.COM (des-cbc-crc)
>   2 11/24/11 23:48:25 PONTUS$@EXAMPLE.COM (des-cbc-md5)
>   2 11/24/11 23:48:25 PONTUS$@EXAMPLE.COM (arcfour-hmac)

Yep, looks normal.
> But using this ticket now fails, in sssd and also with kinit, both with
> 'cred. not found':
>
> # kinit -V -k -t /etc/krb5.keytab host/[e-mail]
> Using default cache: /tmp/krb5cc_0
> Using principal: host/[e-mail]
> Using keytab: /etc/krb5.keytab
> kinit: Client 'host/[e-mail]' not found in Kerberos database while getting initial credentials

If you do a net ads join without any other parameters, the credential that'll
work is the PONTUS$ cred, not the others.

So "kinit -k PONTUS$" should work.
> SSSD: (Thu Nov 24 23:54:03 2011) [[sssd[ldap_child[931]]]]
> [ldap_child_get_tgt_sync] (0): Failed to init credentials: Client
> 'host/[e-mail]' not found in Kerberos database
>
> Principal is listed in "klist", but not found by "kinit"? What did I do wrong this time?

Are you running 1.5 or 1.6?  If you're running 1.6 I'd have expected this to
work as long as you'd not specified which principal to use in your sssd.conf.
If you're running 1.5, you should be specifying to use the PONTUS$ cred.

Entries in the keytab can be userPrincipals or servicePrincipals.  A service
pricipal is basically a receptor, and you can't generate a TGT from it (which
is what kinit does).  When you join to AD to can control what userPrincipal is
created.  AFAIK HOSTNAME$ is always a user principal, but you can also make
one other a user principal using createupn=blah.

jh

[Ondrej Valousek]

> If you do a net ads join without any other parameters, the credential that'll
> work is the PONTUS$ cred, not the others.
>
> So "kinit -k PONTUS$" should work.

Always the same story - people get confused by the UPN (User Principal Name) and SPN (Service Principal Name) meaning.
We should write it down somewhere using bold letters so everyone knows....

Ondrej

[Josh Geisser]

Yes, totally confused :)

Thanks to you guy's I got it working now. But what I don't get is how Kerberos keys are handled in general. The /etc/krb5.keytab is a container, can I take both, UPN and SPN?

So far so good, start testing failover behaviour if the remote DC's are not available

Thanks a lot & cheers
Josh

________________________________________
Von: [e-mail] [mailto:[e-mail]] Im Auftrag von Ondrej Valousek
Gesendet: Freitag, 25. November 2011 16:37
An: [e-mail]
Betreff: Re: [SSSD] GSSAPI and Kerberos - understanding question
> If you do a net ads join without any other parameters, the credential >that'll
> work is the PONTUS$ cred, not the others.
>
> So "kinit -k PONTUS$" should work.

Always the same story - people get confused by the UPN (User Principal Name) and SPN (Service Principal Name) meaning.
We should write it down somewhere using bold letters so everyone knows....

Ondrej

[John Hodrien]

On Sun, 27 Nov 2011, Josh Geisser wrote:
> Yes, totally confused :)
>
> Thanks to you guy's I got it working now. But what I don't get is how
> Kerberos keys are handled in general. The /etc/krb5.keytab is a container,
> can I take both, UPN and SPN?

Yes.  My understanding is the only difference between a service principal and
a user principal is that the KDC will not issue a ticket granting ticket to a
service principal.

jh

[Ondrej Valousek]

On 11/28/2011 09:46 AM, John Hodrien wrote:
> On Sun, 27 Nov 2011, Josh Geisser wrote:
> > Yes, totally confused :)
> >
> > Thanks to you guy's I got it working now. But what I don't get is how
> > Kerberos keys are handled in general. The /etc/krb5.keytab is a container,
> > can I take both, UPN and SPN?
>
> Yes.  My understanding is the only difference between a service principal and
> a user principal is that the KDC will not issue a ticket granting ticket to a
> service principal.
>
> jh

Yes and it is no wonder  because UPN and SPN serve a different task. I recommend searching MS technet for this. They have a nice explanation 
for this.

[John Hodrien]

On Mon, 28 Nov 2011, Ondrej Valousek wrote:
> Yes.  My understanding is the only difference between a service principal and
> a user principal is that the KDC will not issue a ticket granting ticket to a
> service principal.
>
> jh
>
> Yes and it is no wonder  because UPN and SPN serve a different task. I
> recommend searching MS technet for this. They have a nice explanation for
> this.

In simple terms it's service for a receiver and user for initiator.
Unfortunately this can sometimes get a little blury.  NFSv4 is a good example
of that.

jh

[Ondrej Valousek]

On 11/28/2011 10:16 AM, John Hodrien wrote:
> On Mon, 28 Nov 2011, Ondrej Valousek wrote:
> > Yes.  My understanding is the only difference between a service principal and
> > a user principal is that the KDC will not issue a ticket granting ticket to a
> > service principal.
> >
> > jh
> >
> > Yes and it is no wonder  because UPN and SPN serve a different task. I
> > recommend searching MS technet for this. They have a nice explanation for
> > this.
>
> In simple terms it's service for a receiver and user for initiator.
> Unfortunately this can sometimes get a little blury.  NFSv4 is a good example
> of that.

Exactly :-) . In NFSv4 the rpc.gssd expect the UPN and rpc.svcgssd SPN - and none is going to tell you this as none expect you will use 
Windows based KDC for NFSv4... :-( . In Linux based KDC there is no strict distinction for these I believe (citation needed here).

[Marko Myllynen]

Hi,
> > > Yes and it is no wonder  because UPN and SPN serve a different task. I
> > > recommend searching MS technet for this. They have a nice explanation
> > > for this.
> >
> > In simple terms it's service for a receiver and user for initiator.
> > Unfortunately this can sometimes get a little blury.  NFSv4 is a good
> > example of that.
>
> Exactly :-) . In NFSv4 the rpc.gssd expect the UPN and rpc.svcgssd SPN -
> and none is going to tell you this as none expect you will use Windows
> based KDC for NFSv4... :-( . In Linux based KDC there is no strict
> distinction for these I believe (citation needed here).

MIT KDC provides related functionality but as the documentation suggests
it is probably something most people do not want to use.

5.3.3 Adding or Modifying Principals

{-|+}allow_svr
    The “-allow_svr” flag prohibits the issuance of service tickets for
this principal. “+allow_svr” clears this flag. In effect, “-allow_svr”
sets the KRB5_KDB_DISALLOW_SVR flag on the principal in the database.
{-|+}allow_tgs_req
    The “-allow_tgs_req” option specifies that a Ticket-Granting Service
(TGS) request for a service ticket for this principal is not permitted.
You will probably never need to use this option. “+allow_tgs_req” clears
this flag. The default is “+allow_tgs_req”. In effect, “-allow_tgs_req”
sets the KRB5_KDB_DISALLOW_TGT_BASED flag on the principal in the database.

http://web.mit.edu/kerberos/krb5-1.9/krb5-1.9.2/doc/krb5-admin.html

Cheers,

[Ondrej Valousek]

On 11/28/2011 10:49 AM, Marko Myllynen wrote:
> MIT KDC provides related functionality but as the documentation suggests
> it is probably something most people do not want to use.
>
> 5.3.3 Adding or Modifying Principals
>
> {-|+}allow_svr
>      The “-allow_svr” flag prohibits the issuance of service tickets for
> this principal. “+allow_svr” clears this flag. In effect, “-allow_svr”
> sets the KRB5_KDB_DISALLOW_SVR flag on the principal in the database.
> {-|+}allow_tgs_req
>      The “-allow_tgs_req” option specifies that a Ticket-Granting Service
> (TGS) request for a service ticket for this principal is not permitted.
> You will probably never need to use this option. “+allow_tgs_req” clears
> this flag. The default is “+allow_tgs_req”. In effect, “-allow_tgs_req”
> sets the KRB5_KDB_DISALLOW_TGT_BASED flag on the principal in the database.
>
> http://web.mit.edu/kerberos/krb5-1.9/krb5-1.9.2/doc/krb5-admin.html

Thanks for this. The thing is, that the SPN multi-list attribute in Windows means which TGS can be supplied based on a received TGT. That 
means that you can quite nicely limit the functionality - for example if you know your LDAP server will only serve ldap requests and nothing 
else, in a SPN attribute for this machine you specify 'ldap/host@REALM' making sure it could never be misused for say NFSv4.

I am unsure whether you could achieve something like that in MIT using the switches above.
Ondrej

[Simo Sorce]

On Mon, 2011-11-28 at 10:13 +0100, Ondrej Valousek wrote:
> On 11/28/2011 09:46 AM, John Hodrien wrote:
> > On Sun, 27 Nov 2011, Josh Geisser wrote:
> > > Yes, totally confused :)
> > >
> > > Thanks to you guy's I got it working now. But what I don't get is how
> > > Kerberos keys are handled in general. The /etc/krb5.keytab is a container,
> > > can I take both, UPN and SPN?
> >
> > Yes.  My understanding is the only difference between a service principal and
> > a user principal is that the KDC will not issue a ticket granting ticket to a
> > service principal.
> >
> > jh
>
> Yes and it is no wonder  because UPN and SPN serve a different task. I
> recommend searching MS technet for this. They have a nice explanation
> for this.

It's an artificial distinction that holds ground only in MS-land.

If you find the Technet article can you send the link to this list ?

It would be nice to have a reference in the archives.

Simo.

[Ondrej Valousek]

> It's an artificial distinction that holds ground only in MS-land.
>
> If you find the Technet article can you send the link to this list ?
>
> It would be nice to have a reference in the archives.
>
> Simo.

I do not think so - see my post earlier today. I think it actually makes a sense in terms of improved security. You can tell your KDC which 
TGS tickets can be issued for a specified machine.
I good article is here:
http://technet.microsoft.com/en-us/library/cc755804%28WS.10%29.aspx

[John Hodrien]

On Mon, 28 Nov 2011, Ondrej Valousek wrote:
> I do not think so - see my post earlier today. I think it actually makes a
> sense in terms of improved security. You can tell your KDC which TGS tickets
> can be issued for a specified machine.
> I good article is here:
> http://technet.microsoft.com/en-us/library/cc755804%28WS.10%29.aspx

It wasn't clear to me what security benefit you're describing here.  What
*specifically* do you think this improves security wise?

I wasn't clear how you could use this to tell your KDC which TGS tickets can
be issued for a specified machine, given the specified machine's kerberos
credential is allowed to create new service principals.

jh

[Ondrej Valousek]

> It wasn't clear to me what security benefit you're describing here.  What
> *specifically* do you think this improves security wise?

Example:
Say you have NFS server 'polaris' and NFS client 'deneb'. You want to mount polaris share on deneb using krb5 security. For this you need 
nfs/ principals in /etc/krb5.keytab on both machines.
On deneb you need a UPN principal in form of nfs/.... for the rpc.gssd daemon because it is not treated as a service principal, in reality 
it is used to get a TGT so hence it must be UPN
On polaris1 you also need a nfs/ principal, but it is sufficient to be a SPN. Polaris1 machine is Server providing a Service so hence SPN is 
fine here to make rpc.svcgssd happy.

And how does it affect security? Easily - if you declare nfs/ UPN principal for deneb and nfs/ SPN principal for polaris, you making sure 
that only polaris can be used as a NFS server and deneb as a NFS client and not vice-versa.

[John Hodrien]

On Thu, 1 Dec 2011, Ondrej Valousek wrote:
> And how does it affect security? Easily - if you declare nfs/ UPN principal
> for deneb and nfs/ SPN principal for polaris, you making sure that only
> polaris can be used as a NFS server and deneb as a NFS client and not
> vice-versa.

NFS is a freaky oddity though.  You've done nothing to stop me running pretty
much any other service I like.

jh

[Ondrej Valousek]

On 12/01/2011 04:58 PM, John Hodrien wrote:
> On Thu, 1 Dec 2011, Ondrej Valousek wrote:
> > And how does it affect security? Easily - if you declare nfs/ UPN principal
> > for deneb and nfs/ SPN principal for polaris, you making sure that only
> > polaris can be used as a NFS server and deneb as a NFS client and not
> > vice-versa.
>
> NFS is a freaky oddity though.  You've done nothing to stop me running pretty
> much any other service I like.
>
> jh

Kerberos can not protect you against a malicious root, but it can very well protect you against a malicious user. So if you are a common 
user, it is very easy to lock the system down the way so you have to use say NFS/Kerberos or nothing else.

That's a different story though...

[Josh Geisser]

Hi again

Just wanted to finish up this topic. Great reading this technet article, the whole thing makes a lot more sense now. Definitely worth mentioning in the documentation.

Also worth mentioning is that depending on Active directory configuration, the distribution of the key between the domain controllers can take several minutes.

So far so good, thanks a lot for your support gents
Cheers
Josh

-----Ursprüngliche Nachricht-----
Von: [e-mail] [mailto:[e-mail]] Im Auftrag von John Hodrien
Gesendet: Montag, 28. November 2011 18:02
An: Development of the System Security Services Daemon
Betreff: Re: [SSSD] GSSAPI and Kerberos - understanding question

On Mon, 28 Nov 2011, Ondrej Valousek wrote:
> I do not think so - see my post earlier today. I think it actually makes a
> sense in terms of improved security. You can tell your KDC which TGS tickets
> can be issued for a specified machine.
> I good article is here:
> http://technet.microsoft.com/en-us/library/cc755804%28WS.10%29.aspx

It wasn't clear to me what security benefit you're describing here.  What
*specifically* do you think this improves security wise?

I wasn't clear how you could use this to tell your KDC which TGS tickets can
be issued for a specified machine, given the specified machine's kerberos
credential is allowed to create new service principals.

jh
_______________________________________________
sssd-devel mailing list
[e-mail]
https://fedorahosted.org/mailman/listinfo/sssd-devel

[Ondrej Valousek]

Maybe some volunteer to write some document on a sssd wiki page?
I do not have access myself.....

Ondrej

On 12/14/2011 10:21 AM, Josh Geisser wrote:
> Hi again
>
> Just wanted to finish up this topic. Great reading this technet article, the whole thing makes a lot more sense now. Definitely worth mentioning in the documentation.
>
> Also worth mentioning is that depending on Active directory configuration, the distribution of the key between the domain controllers can take several minutes.
>
> So far so good, thanks a lot for your support gents
> Cheers
> Josh
>
> -----Ursprüngliche Nachricht-----
> Von: [e-mail] [mailto:[e-mail]] Im Auftrag von John Hodrien
> Gesendet: Montag, 28. November 2011 18:02
> An: Development of the System Security Services Daemon
> Betreff: Re: [SSSD] GSSAPI and Kerberos - understanding question
>
> On Mon, 28 Nov 2011, Ondrej Valousek wrote:
> > I do not think so - see my post earlier today. I think it actually makes a
> > sense in terms of improved security. You can tell your KDC which TGS tickets
> > can be issued for a specified machine.
> > I good article is here:
> > http://technet.microsoft.com/en-us/library/cc755804%28WS.10%29.aspx
>
> It wasn't clear to me what security benefit you're describing here.  What
> *specifically* do you think this improves security wise?
>
> I wasn't clear how you could use this to tell your KDC which TGS tickets can
> be issued for a specified machine, given the specified machine's kerberos
> credential is allowed to create new service principals.
>
> jh
> _______________________________________________
> sssd-devel mailing list
> [e-mail]
> https://fedorahosted.org/mailman/listinfo/sssd-devel

[John Hodrien]

On Wed, 14 Dec 2011, Ondrej Valousek wrote:
> Maybe some volunteer to write some document on a sssd wiki page?
> I do not have access myself.....

There already is a page on Active Directory with sssd:

https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...

If you think a different page is needed for a more general kerberos and ldap
setup, I doubt you'll get complaints if you write it.

AFAIK you can edit it as long as you have a fedora account:

https://admin.fedoraproject.org/accounts/

Certainly I've been able to edit documentation, and have no special rights.

jh

[Stephen Gallagher]

On Dec 14, 2011, at 5:19 AM, John Hodrien  wrote:
> On Wed, 14 Dec 2011, Ondrej Valousek wrote:
> > Maybe some volunteer to write some document on a sssd wiki page?
> > I do not have access myself.....
>
> There already is a page on Active Directory with sssd:
>
> https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...
>
> If you think a different page is needed for a more general kerberos and ldap
> setup, I doubt you'll get complaints if you write it.

Please do!
> AFAIK you can edit it as long as you have a fedora account:
>
> https://admin.fedoraproject.org/accounts/
>
> Certainly I've been able to edit documentation, and have no special rights.

Correct, anyone who signs up for a free account at the link above has edit rights to nearly every page on the wiki. The only exceptions are the front page and the release pages (so no one can tamper with the checksums for the release tarballs).
> jh
> _______________________________________________
> sssd-devel mailing list
> [e-mail]
> https://fedorahosted.org/mailman/listinfo/sssd-devel

[Ondrej Valousek]

Updated the wiki page:
https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...
with my findings....

Ondrej

On 12/14/2011 12:13 PM, Stephen Gallagher wrote:
> On Dec 14, 2011, at 5:19 AM, John Hodrien  wrote:
> > On Wed, 14 Dec 2011, Ondrej Valousek wrote:
> > > Maybe some volunteer to write some document on a sssd wiki page?
> > > I do not have access myself.....
> >
> > There already is a page on Active Directory with sssd:
> >
> > https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...
> >
> > If you think a different page is needed for a more general kerberos and ldap
> > setup, I doubt you'll get complaints if you write it.
>
> Please do!
> > AFAIK you can edit it as long as you have a fedora account:
> >
> > https://admin.fedoraproject.org/accounts/
> >
> > Certainly I've been able to edit documentation, and have no special rights.
>
> Correct, anyone who signs up for a free account at the link above has edit rights to nearly every page on the wiki. The only exceptions are the front page and the release pages (so no one can tamper with the checksums for the release tarballs).
> > jh
> > _______________________________________________
> > sssd-devel mailing list
> > [e-mail]
> > https://fedorahosted.org/mailman/listinfo/sssd-devel
>
> sssd-devel mailing list
> [e-mail]
> https://fedorahosted.org/mailman/listinfo/sssd-devel

[Greg Lehmann]

Just a comment on the wiki, that I’d like verified before changing it. There is now no need for NIS to be setup for sssd to work with AD (2008R2.)

From: [e-mail] [mailto:[e-mail]] On Behalf Of Ondrej Valousek
Sent: Monday, 19 December 2011 6:25 PM
To: [e-mail]
Subject: Re: [SSSD] GSSAPI and Kerberos - understanding question

Updated the wiki page:
https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...
with my findings....

Ondrej

On 12/14/2011 12:13 PM, Stephen Gallagher wrote:

On Dec 14, 2011, at 5:19 AM, John Hodrien  wrote:

On Wed, 14 Dec 2011, Ondrej Valousek wrote:

Maybe some volunteer to write some document on a sssd wiki page?

I do not have access myself.....

There already is a page on Active Directory with sssd:

https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...

If you think a different page is needed for a more general kerberos and ldap

setup, I doubt you'll get complaints if you write it.

Please do!

AFAIK you can edit it as long as you have a fedora account:

https://admin.fedoraproject.org/accounts/

Certainly I've been able to edit documentation, and have no special rights.

Correct, anyone who signs up for a free account at the link above has edit rights to nearly every page on the wiki. The only exceptions are the front page and the release pages (so no one can tamper with the checksums for the release tarballs).

jh

_______________________________________________

sssd-devel mailing list

[e-mail]

https://fedorahosted.org/mailman/listinfo/sssd-devel

_______________________________________________

sssd-devel mailing list

[e-mail]

https://fedorahosted.org/mailman/listinfo/sssd-devel

[Ondrej Valousek]

That's correct.
Ondrej

On 12/20/2011 02:10 AM, [e-mail] wrote:
> Just a comment on the wiki, that I’d like verified before changing it. There is now no need for NIS to be setup for sssd to work with AD 
> (2008R2.)
>
> *From:*[e-mail] [mailto:[e-mail]] *On Behalf Of *Ondrej Valousek
> *Sent:* Monday, 19 December 2011 6:25 PM
> *To:* [e-mail]
> *Subject:* Re: [SSSD] GSSAPI and Kerberos - understanding question
>
> Updated the wiki page:
> https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...
> with my findings....
>
> Ondrej
>
> On 12/14/2011 12:13 PM, Stephen Gallagher wrote:
>
> On Dec 14, 2011, at 5:19 AM, John Hodrien    wrote:
> On Wed, 14 Dec 2011, Ondrej Valousek wrote:
>
>
>
>     Maybe some volunteer to write some document on a sssd wiki page?
>
>     I do not have access myself.....
>
>
>
> There already is a page on Active Directory with sssd:
>
>
>
> https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20with%20a%20Windows%202008%20Domain%20Server
>
>
>
> If you think a different page is needed for a more general kerberos and ldap
>
> setup, I doubt you'll get complaints if you write it.
>
>
>
>
> Please do!
> AFAIK you can edit it as long as you have a fedora account:
>
>
>
> https://admin.fedoraproject.org/accounts/
>
>
>
> Certainly I've been able to edit documentation, and have no special rights.
>
>
>
>
> Correct, anyone who signs up for a free account at the link above has edit rights to nearly every page on the wiki. The only exceptions are the front page and the release pages (so no one can tamper with the checksums for the release tarballs).
> jh
>
> _______________________________________________
>
> sssd-devel mailing list
>
> [e-mail]  <mailto:[e-mail]>
>
> https://fedorahosted.org/mailman/listinfo/sssd-devel
>
> sssd-devel mailing list
> [e-mail]  
> https://fedorahosted.org/mailman/listinfo/sssd-devel
>
> sssd-devel mailing list
> [e-mail]
> https://fedorahosted.org/mailman/listinfo/sssd-devel

[Josh Geisser]

Might it be that one?
http://technet.microsoft.com/en-us/library/cc772815%28WS.10%29.aspx

-----Ursprüngliche Nachricht-----
Von: [e-mail] [mailto:[e-mail]] Im Auftrag von Simo Sorce
Gesendet: Montag, 28. November 2011 17:36
An: Development of the System Security Services Daemon
Betreff: Re: [SSSD] GSSAPI and Kerberos - understanding question

On Mon, 2011-11-28 at 10:13 +0100, Ondrej Valousek wrote:
> On 11/28/2011 09:46 AM, John Hodrien wrote:
> > On Sun, 27 Nov 2011, Josh Geisser wrote:
> > > Yes, totally confused :)
> > >
> > > Thanks to you guy's I got it working now. But what I don't get is how
> > > Kerberos keys are handled in general. The /etc/krb5.keytab is a container,
> > > can I take both, UPN and SPN?
> >
> > Yes.  My understanding is the only difference between a service principal and
> > a user principal is that the KDC will not issue a ticket granting ticket to a
> > service principal.
> >
> > jh
>
> Yes and it is no wonder  because UPN and SPN serve a different task. I
> recommend searching MS technet for this. They have a nice explanation
> for this.

It's an artificial distinction that holds ground only in MS-land.

If you find the Technet article can you send the link to this list ?

It would be nice to have a reference in the archives.

Simo.