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
ekacnet, could you take care about this?
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.
Created attachment 6019 [details] Patch for fixing the search path of ldbsearch
Created attachment 6020 [details] Patch proposal for fixing this bug
(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.
> 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.
(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.
(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 ?
(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.
(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.
Trever, Finally what is the status of this bug ? should we close it ?
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.
Close with status invalid