Bug 7739 - ktpass.sh MUST add appropriate userPrincipalName
ktpass.sh MUST add appropriate userPrincipalName
Status: RESOLVED INVALID
Product: Samba 4.0
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB
unspecified
Other Linux
: P3 major
: ---
Assigned To: Matthieu Patou
samba4-qa@samba.org
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-10-19 07:32 UTC by Trever Adams
Modified: 2010-11-05 13:13 UTC (History)
0 users

See Also:


Attachments
Patch for fixing the search path of ldbsearch (852 bytes, patch)
2010-10-19 08:27 UTC, Matthieu Patou
no flags Details
Patch proposal for fixing this bug (1.09 KB, patch)
2010-10-19 08:27 UTC, Matthieu Patou
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Trever Adams 2010-10-19 07:32:12 UTC
The userPrincipalName is actually required by some programs for things
to work properly. One example of this is dovecot SASL being used by
postfix (client Thunderberd 3.1.4) for smtp. I have been trying to get
this to work for about a week.

Just for grins, I added the userPrincipalName in the format of service/f.q.d.n@REALM (service=smtp in this case) and now everything works great.

Any fix to ktpass.sh would be GREATLY appreciated.

Thank you,
Trever Adams
Comment 1 Matthias Dieter Wallnöfer 2010-10-19 07:50:50 UTC
ekacnet,

could you take care about this?
Comment 2 Matthieu Patou 2010-10-19 08:26:14 UTC
Hi trever, 
Not sure I completely get the request here.

Do you mean that we have also to search for userPrincipalName when searching for kvno because after what you give to ktutil is not checked.

Have a look at the attached patches.
Comment 3 Matthieu Patou 2010-10-19 08:27:02 UTC
Created attachment 6019 [details]
Patch for fixing the search path of ldbsearch
Comment 4 Matthieu Patou 2010-10-19 08:27:25 UTC
Created attachment 6020 [details]
Patch proposal for fixing this bug
Comment 5 Trever Adams 2010-10-19 08:38:40 UTC
(In reply to comment #2)
> Hi trever, 
> Not sure I completely get the request here.
> 
> Do you mean that we have also to search for userPrincipalName when searching
> for kvno because after what you give to ktutil is not checked.
> 
> Have a look at the attached patches.
> 

This is all that I know: Before I modified the userPrincipalName whenever a client of smtp services (postfix using dovecot sasl) would try to log in via gssapi, I would get a log entry saying it couldn't find smtp/mail_host_fqdn@REALM. Once I added the userPrincipalName everything (in Linux) works.

None of your suggested patches seem to do this. Like my recent request that net newuser add the userPrincipalName, this bug is about the fact that userPrincipalName isn't being set proplery to the form of service/fqdn@REALM by ktpass.

Additionally, I hadn't tested Windows Thunderbird until just now and found that it doesn't fix the problem for Windows, but does indeed make all the difference for Linux Thunderbird.

I don't even think Samba4 is being talked to with Windows Thunderbird smtp in the setup described. It is for imap, which is most strange.


Comment 6 Matthieu Patou 2010-10-19 10:45:59 UTC
> This is all that I know: Before I modified the userPrincipalName whenever a
> client of smtp services (postfix using dovecot sasl) would try to log in via
> gssapi, I would get a log entry saying it couldn't find
> smtp/mail_host_fqdn@REALM. Once I added the userPrincipalName everything (in
> Linux) works.
> 
Ok so you need smtp/mail.mydomain.com@MYDOMAIN.COM, have you tried to add to a dedicated account this principal? Normaly the way to do kerberized auth is the following: you add a technical account that "represent the user/server". You add a spn to it. 

Then when a user wants to connect to your mail server he ask for smtp/mail.mydomain.com@MYDOMAIN ticket to the kdc, the kdc will look at some record like userprincipalname or serviceprincipalname to find the real user (and the real password) in order to return you a ticket with a proof of the user's password so that your server can check with it's password (stored in the keytab) that the ticket is legit.
Comment 7 Trever Adams 2010-10-19 11:22:01 UTC
(In reply to comment #6)
>
> Ok so you need smtp/mail.mydomain.com@MYDOMAIN.COM, have you tried to add to a
> dedicated account this principal? Normaly the way to do kerberized auth is the
> following: you add a technical account that "represent the user/server". You
> add a spn to it. 
> 
> Then when a user wants to connect to your mail server he ask for
> smtp/mail.mydomain.com@MYDOMAIN ticket to the kdc, the kdc will look at some
> record like userprincipalname or serviceprincipalname to find the real user
> (and the real password) in order to return you a ticket with a proof of the
> user's password so that your server can check with it's password (stored in the
> keytab) that the ticket is legit.
> 

Yes this is correct. I did this:
/usr/local/samba/bin/net newuser imap-MAILSERVERHOST
/usr/local/samba/bin/net newuser smtp-MAILSERVERHOST
/usr/local/samba/bin/net spn add imap/FQDN_MAILSERVER imap-MAILSERVER_HOST
/usr/local/samba/bin/net spn add smtp/MAILSERVER_FQDN smtp-MAILSERVER_HOST
/root/samba-master/source4/scripting/bin/ktpass.sh --out /tmp/dovecot.keytab --princ smtp/MAILSERVER_FQDN --path-to-ldbsearch /usr/local/samba/bin/ --pass RANDOMPASSWORD_SET_ABOVE
/usr/local/samba/bin/net spn add imap/FQDN_MAILSERVER smtp-MAILSERVER_HOST
/root/samba-master/source4/scripting/bin/ktpass.sh --out /tmp/dovecot.keytab --princ imap/MAILSERVER_FQDN --path-to-ldbsearch /usr/local/samba/bin/ --pass RANDOMPASSWORD_SET_ABOVE

It sets the servicePrincipalName to imap/mailserver but doesn't set the userPrincipalName to imap/mailserver@REALM. Which, at least by some programs, is required. Leading to me finding the Samba4 log (-d 9) of not finding the userPrincipalName.

The ktpass stuff above should have added that. The windows variant does at least according to srikumar108@gmail.com in an email to mat@samba.org on Samba-technical, quoting:

"2. 'ldbedit -H sam.lbd cn=imap' to add the following:
servicePrincipalName: imap/.f.q.d.n
userPrincipalName: imap/f.q.d.n@REALM

The 'userPrincipalName' entry is added by Windows ktpass.exe, but it
was not strictly necessary. The trick was to add the serviceprincipal
WITHOUT the realm part."

The problem is, at least for some programs, the userPrincipalName is necessary. Why only some, I do not know! In the example of what I ran above, dovecot is doing ALL the gssapi/kerberos stuff. Directly it works, when acting as SASL for postfix, it requires the userPrincipalName.

I find it strange.

Comment 8 Matthieu Patou 2010-10-19 14:22:11 UTC
(In reply to comment #7)
> (In reply to comment #6)
> >
> > Ok so you need smtp/mail.mydomain.com@MYDOMAIN.COM, have you tried to add to a
> > dedicated account this principal? Normaly the way to do kerberized auth is the
> > following: you add a technical account that "represent the user/server". You
> > add a spn to it. 
> > 
> > Then when a user wants to connect to your mail server he ask for
> > smtp/mail.mydomain.com@MYDOMAIN ticket to the kdc, the kdc will look at some
> > record like userprincipalname or serviceprincipalname to find the real user
> > (and the real password) in order to return you a ticket with a proof of the
> > user's password so that your server can check with it's password (stored in the
> > keytab) that the ticket is legit.
> > 
> 
> Yes this is correct. I did this:
> /usr/local/samba/bin/net newuser imap-MAILSERVERHOST
> /usr/local/samba/bin/net newuser smtp-MAILSERVERHOST
> /usr/local/samba/bin/net spn add imap/FQDN_MAILSERVER imap-MAILSERVER_HOST
> /usr/local/samba/bin/net spn add smtp/MAILSERVER_FQDN smtp-MAILSERVER_HOST
> /root/samba-master/source4/scripting/bin/ktpass.sh --out /tmp/dovecot.keytab
> --princ smtp/MAILSERVER_FQDN --path-to-ldbsearch /usr/local/samba/bin/ --pass
> RANDOMPASSWORD_SET_ABOVE
> /usr/local/samba/bin/net spn add imap/FQDN_MAILSERVER smtp-MAILSERVER_HOST
> /root/samba-master/source4/scripting/bin/ktpass.sh --out /tmp/dovecot.keytab
> --princ imap/MAILSERVER_FQDN --path-to-ldbsearch /usr/local/samba/bin/ --pass
> RANDOMPASSWORD_SET_ABOVE
> 
> It sets the servicePrincipalName to imap/mailserver but doesn't set the
> userPrincipalName to imap/mailserver@REALM
Yeah it does what you ask have you tried /usr/local/samba/bin/net spn add imap/mailserver@REALM smtp-MAILSERVER_HOST ?
Also did you know that you can associate more than 1 SPN to a user (even 10 or 100).


, at least by some programs,
> is required. Leading to me finding the Samba4 log (-d 9) of not finding the
> userPrincipalName.
Can you put the log ?
Comment 9 Trever Adams 2010-10-21 13:20:15 UTC
(In reply to comment #8)
> Yeah it does what you ask have you tried /usr/local/samba/bin/net spn add
> imap/mailserver@REALM smtp-MAILSERVER_HOST ?
> Also did you know that you can associate more than 1 SPN to a user (even 10 or
> 100).

No, I haven't tried adding multiple SPNs to a single user. I didn't know it was possible (I knew that at least some LDAP attributes could be used multiple times in an account, but I didn't know which and if S4 supported it).

I may try that in the future.

> 
> Can you put the log ?

Sorry, the server hasn't been dormant at a time I could do this for a few days. I hope to do it tonight. If it turns out the change isn't needed, mixed with the fact that multiple SPNs can be added to a single user, then I would say don't fix this.

Please, wait until I can test and provide the log before closing the bug. 

Comment 10 Trever Adams 2010-10-25 03:12:11 UTC
(In reply to comment #8)
I cannot explain this. Sometimes it won't work. Once it starts working, it stays working.

Maybe mark this as NOT A BUG, I do not know.I had created the entry showing the log but accidentally hit control-R. I cannot duplicate it now. Things are working. Sorry for the noise.
Comment 11 Matthieu Patou 2010-10-27 13:44:09 UTC
Trever,

Finally what is the status of this bug ? should we close it ?
Comment 12 Trever Adams 2010-10-28 02:33:03 UTC
I still do not know why it doesn't work at first. It does work after restarting dovecot, postfix, and samba. I am wondering if something is caching negative at first and this is what is causing it.

Close the bug as Not a bug I guess.

Thank you for all your hard work. Sorry for the false alarm.
Comment 13 Matthieu Patou 2010-11-05 13:13:51 UTC
Close with status invalid