Hi everyone,
I'm trying to figure out the best way to accomplish below project and would appreciate your input.
I need to setup a web page on CentOS with Active Directory authentication.
So far I've accomplished the following:
- Setup httpd.conf to successfully authenticate against AD by passing my username/passwd.
<Directory /var/www/html/secure> Allow from All AuthType Basic AuthName "Ldap test area" AuthBasicProvider ldap AuthzLDAPAuthoritative on AuthLDAPURL "ldap://server:389/OU=OU=name,OU=area,DC=core,DC=test,DC=edu?sAMAccountName?sub?(objectClass=*)" AuthLDAPBindDN "username@core" AuthLDAPBindPassword password require valid-user </Directory>
- In addition, I used LikeWise software and was able to successfully join AD.
I was wondering if there is a way to do http authentication without passing my username/password considering server is already binded to AD, thus authenticated.
Would I be able to utilize PAM authentication for this purpose?
# httpd -v Server version: Apache/2.2.3 Server built: Aug 30 2010 12:28:40 # more /etc/redhat-release CentOS release 5.5 (Final)
Thank you! Asya
On Wed, 9 Mar 2011, Dvorkin, Asya wrote:
I was wondering if there is a way to do http authentication without passing my username/password considering server is already binded to AD, thus authenticated.
Would I be able to utilize PAM authentication for this purpose?
mod_auth_kerb can use kerberos tickets to handle the authentication, thus avoiding the need to pass a username and password to the web server.
jh
Thank you, John.
I forgot to add that we cannot generate keytab from AD server for various reasons that I have no control over.
Would mod_auth_kerb still work? My google searches all point to keytab file being there...
Thank you, Asya
On Mar 9, 2011, at 9:35 AM, John Hodrien wrote:
On Wed, 9 Mar 2011, Dvorkin, Asya wrote:
I was wondering if there is a way to do http authentication without passing my username/password considering server is already binded to AD, thus authenticated.
Would I be able to utilize PAM authentication for this purpose?
mod_auth_kerb can use kerberos tickets to handle the authentication, thus avoiding the need to pass a username and password to the web server.
jh _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Wed, 9 Mar 2011, Dvorkin, Asya wrote:
Thank you, John.
I forgot to add that we cannot generate keytab from AD server for various reasons that I have no control over.
Would mod_auth_kerb still work? My google searches all point to keytab file being there...
Yes. If you join AD properly you can get a keytab out of it. If you don't have a keytab, how are you proposing this single sign on is going to work?
jh
On Wed, 9 Mar 2011, John Hodrien wrote:
On Wed, 9 Mar 2011, Dvorkin, Asya wrote:
Thank you, John.
I forgot to add that we cannot generate keytab from AD server for various reasons that I have no control over.
And are you really sure this is the case? If you can join to a domain, you can get a keytab (you don't need AD admin rights to do this).
If you were just using Samba to do the join, something like:
use kerberos keytab = yes
in your smb.conf
and a:
net ads keytab create net ads keytab add http
on the joined machine would get you a keytab suitable for web auth.
klist -k would then show you what you'd got.
jh
John,
Thank you for all your pointers! You are right.. I was able to create a keytab file. Still having some issues with getting apache to work the way I wan to, but will continue troubleshooting it.
Thank you! Asya
On Mar 9, 2011, at 10:09 AM, John Hodrien wrote:
On Wed, 9 Mar 2011, John Hodrien wrote:
On Wed, 9 Mar 2011, Dvorkin, Asya wrote:
Thank you, John.
I forgot to add that we cannot generate keytab from AD server for various reasons that I have no control over.
And are you really sure this is the case? If you can join to a domain, you can get a keytab (you don't need AD admin rights to do this).
If you were just using Samba to do the join, something like:
use kerberos keytab = yes
in your smb.conf
and a:
net ads keytab create net ads keytab add http
on the joined machine would get you a keytab suitable for web auth.
klist -k would then show you what you'd got.
jh _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Thu, 10 Mar 2011, Dvorkin, Asya wrote:
John,
Thank you for all your pointers! You are right.. I was able to create a keytab file. Still having some issues with getting apache to work the way I wan to, but will continue troubleshooting it.
No problem, and I'll be interested to hear about any other problems you have. I don't get the feeling many people use kerberised Apache.
jh
Okay... so at this point I am stuck.
I got this far:
Using modules:
LoadModule auth_basic_module modules/mod_auth_basic.so LoadModule auth_kerb_module modules/mod_auth_kerb.so
root@myserver conf]# net ads testjoin Join is OK
I successfully joined domain.
[root@myserver conf]# klist -k Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 2 host/myserver.server.com@CORE.HOST.EDU 2 host/rmyserver.server.com@CORE.HOST.EDU 2 host/myserver.server.com@CORE.HOST.EDU 2 host/myserver@CORE.HOST.EDU 2 host/myserver@CORE.HOST.EDU 2 host/myserver@CORE.HOST.EDU 2 MYSERVER$@CORE.HOST.EDU 2 MYSERVER$@CORE.HOST.EDU 2 MYSERVER$@CORE.HOST.EDU 2 http/myserver.server.com@CORE.HOST.EDU 2 http/myserver.server.com@CORE.HOST.EDU 2 http/myserver.server.com@CORE.HOSTEDU 2 http/myserver@CORE.HOST.EDU 2 http/myserver@CORE.HOST.EDU 2 http/myserver@CORE.HOST.EDU
My problem is that I am getting an error message in apache logs:
gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information (No principal in keytab matches desired name)
I looked in AD configuration and see that my server does not have appropriate ServicePrincipalName for HTTP (only host).
my keytab file: -rw------- 1 apache apache 957 Mar 11 14:31 /etc/httpd/conf/krb5.keytab
I have NO right access to AD server and cannot do much about creating proper keytab file.
Anything else I can do? Am I missing something?
Thank you! Asya
On Mar 10, 2011, at 12:24 PM, John Hodrien wrote:
On Thu, 10 Mar 2011, Dvorkin, Asya wrote:
John,
Thank you for all your pointers! You are right.. I was able to create a keytab file. Still having some issues with getting apache to work the way I wan to, but will continue troubleshooting it.
No problem, and I'll be interested to hear about any other problems you have. I don't get the feeling many people use kerberised Apache.
jh _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
It appears as though you need to create a proper SPN/keytab from the AD server:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.i...
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of David Brian Chait Sent: Friday, March 11, 2011 1:15 PM To: CentOS mailing list Subject: Re: [CentOS] Apache/Active Directory authentication
I looked in AD configuration and see that my server does not have appropriate ServicePrincipalName for HTTP (only host).
Of course it doesn't, you gathered that ticket by joining the domain with Samba, but are not using samba auth with apache... _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Fri, 11 Mar 2011, David Brian Chait wrote:
It appears as though you need to create a proper SPN/keytab from the AD server:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.i...
I've done this just with a net ads keytab add HTTP.
jh
On Fri, 11 Mar 2011, David Brian Chait wrote:
I looked in AD configuration and see that my server does not have appropriate ServicePrincipalName for HTTP (only host).
Of course it doesn't, you gathered that ticket by joining the domain with Samba, but are not using samba auth with apache...
No, he's using mod_auth_kerb. What's wrong with that? What is this 'samba auth' you speak of that lets you do passwordless Negotiate based auth?
jh
On Fri, Mar 11, 2011 at 3:50 PM, Dvorkin, Asya dvorkias@umdnj.edu wrote:
[root@myserver conf]# klist -k Keytab name: FILE:/etc/krb5.keytab KVNO Principal
2 host/myserver.server.com@CORE.HOST.EDU 2 host/rmyserver.server.com@CORE.HOST.EDU 2 host/myserver.server.com@CORE.HOST.EDU 2 host/myserver@CORE.HOST.EDU 2 host/myserver@CORE.HOST.EDU 2 host/myserver@CORE.HOST.EDU 2 MYSERVER$@CORE.HOST.EDU 2 MYSERVER$@CORE.HOST.EDU 2 MYSERVER$@CORE.HOST.EDU 2 http/myserver.server.com@CORE.HOST.EDU 2 http/myserver.server.com@CORE.HOST.EDU 2 http/myserver.server.com@CORE.HOSTEDU 2 http/myserver@CORE.HOST.EDU 2 http/myserver@CORE.HOST.EDU 2 http/myserver@CORE.HOST.EDU
My problem is that I am getting an error message in apache logs:
gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information (No principal in keytab matches desired name)
I looked in AD configuration and see that my server does not have appropriate ServicePrincipalName for HTTP (only host).
Hi Asya,
You must set the servicePrincipalName attribute on the service account (MYSERVER$ in this case) to include all of the hostnames that will be used to access the web server which in this case would be at least "HTTP/myserver.server.com". One way to do this would be to use setspn.exe on a Windows client but if you really have no access to the Windows side as you say, you could use the Samba keytab to acquire credentials for doing the necessary LDAP add operation using some tool (maybe there is a Samba utility for this, I don't know) or program.
Mike
On Mon, 14 Mar 2011, Michael B Allen wrote:
Hi Asya,
You must set the servicePrincipalName attribute on the service account (MYSERVER$ in this case) to include all of the hostnames that will be used to access the web server which in this case would be at least "HTTP/myserver.server.com". One way to do this would be to use setspn.exe on a Windows client but if you really have no access to the Windows side as you say, you could use the Samba keytab to acquire credentials for doing the necessary LDAP add operation using some tool (maybe there is a Samba utility for this, I don't know) or program.
That's not true, and I'm not even sure it's possible from samba (at least, I'm not sure it *should* be possible).
I have a machine with an A record that matches the keytab entry ("real"). The PTR record for the IP goes back that the hostname. There's then a CNAME record for the name used in reality for the web server ("friendly").
A client will access:
https://www.friendly/kerberised
Client correctly pulls down HTTP/real@KRB-REALM, and the authentication works just fine.
jh
On Mon, Mar 14, 2011 at 5:58 AM, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
On Mon, 14 Mar 2011, Michael B Allen wrote:
Hi Asya,
You must set the servicePrincipalName attribute on the service account (MYSERVER$ in this case) to include all of the hostnames that will be used to access the web server which in this case would be at least "HTTP/myserver.server.com". One way to do this would be to use setspn.exe on a Windows client but if you really have no access to the Windows side as you say, you could use the Samba keytab to acquire credentials for doing the necessary LDAP add operation using some tool (maybe there is a Samba utility for this, I don't know) or program.
That's not true, and I'm not even sure it's possible from samba (at least, I'm not sure it *should* be possible).
What's not true? That you can use the Samba keytab to acquire a ticket and perform an LDAP operation on it's own Computer account? It certainly is true. In fact Samba uses the keytab to authenticate with and at least query AD services on a regular basis to perform normal day-to-day operations.
But from looking at you other response I wonder if "net ads keytab ADD HTTP" adds servicePrincipalName attribute values (I don't use Samba like that so I don't know). If is supposed to, and the AD account does not have them, then I agree, something is wrong and he should start over. It could be a replication issue.
I have a machine with an A record that matches the keytab entry ("real"). The PTR record for the IP goes back that the hostname. There's then a CNAME record for the name used in reality for the web server ("friendly").
A client will access:
https://www.friendly/kerberised
Client correctly pulls down HTTP/real@KRB-REALM, and the authentication works just fine.
I don't know what the official view is on going through a CNAME but I think that is probably a dubious practice. The proper way to handle this scenario would be to add another servicePrincipalName value for HTTP/www.friendly and a corresponding keytab entry for HTTP/www.friendly@KRB-REALM.
Mike
On Wed, 16 Mar 2011, Michael B Allen wrote:
On Mon, Mar 14, 2011 at 5:58 AM, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
On Mon, 14 Mar 2011, Michael B Allen wrote:
Hi Asya,
You must set the servicePrincipalName attribute on the service account (MYSERVER$ in this case) to include all of the hostnames that will be used to access the web server which in this case would be at least "HTTP/myserver.server.com". One way to do this would be to use setspn.exe on a Windows client but if you really have no access to the Windows side as you say, you could use the Samba keytab to acquire credentials for doing the necessary LDAP add operation using some tool (maybe there is a Samba utility for this, I don't know) or program.
That's not true, and I'm not even sure it's possible from samba (at least, I'm not sure it *should* be possible).
What's not true? That you can use the Samba keytab to acquire a ticket and perform an LDAP operation on it's own Computer account? It certainly is true. In fact Samba uses the keytab to authenticate with and at least query AD services on a regular basis to perform normal day-to-day operations.
Sorry I overquoted, I'll be more explicit. You said:
"You must set the servicePrincipalName attribute on the service account (MYSERVER$ in this case) to include all of the hostnames that will be used to access the web server"
That just isn't true. You don't need all those principals in, and I can't think of a sane way that'd even be possible. There's no sane way this host credential could be used to generate HTTP/another.fqdn@REALM credentials. Surely?
But from looking at you other response I wonder if "net ads keytab ADD HTTP" adds servicePrincipalName attribute values (I don't use Samba like that so I don't know). If is supposed to, and the AD account does not have them, then I agree, something is wrong and he should start over. It could be a replication issue.
Yes. That command creates servicePrincpalName entries for HTTP with the FQDN and the short name.
I don't know what the official view is on going through a CNAME but I think that is probably a dubious practice. The proper way to handle this scenario would be to add another servicePrincipalName value for HTTP/www.friendly and a corresponding keytab entry for HTTP/www.friendly@KRB-REALM.
Dubious why? If I go with your method at the very least I now need more records in AD for machines that don't exist, and I'm guessing I'll be creating them by being a domain administrator, which is inconvenient in large organisations.
I'm assuming I'll also be needing to add A records for these domains. Kerberos surely won't be a fan of there not being a PTR record, so I assume you'd need multiple PTR records. Is this really the path you're suggesting going down? I'm genuinely interested here, I'm not having a dig.
jh
On Thu, Mar 17, 2011 at 6:18 AM, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
On Wed, 16 Mar 2011, Michael B Allen wrote:
I don't know what the official view is on going through a CNAME but I think that is probably a dubious practice. The proper way to handle this scenario would be to add another servicePrincipalName value for HTTP/www.friendly and a corresponding keytab entry for HTTP/www.friendly@KRB-REALM.
Dubious why? If I go with your method at the very least I now need more records in AD for machines that don't exist, and I'm guessing I'll be creating them by being a domain administrator, which is inconvenient in large organisations.
I'm assuming I'll also be needing to add A records for these domains. Kerberos surely won't be a fan of there not being a PTR record, so I assume you'd need multiple PTR records. Is this really the path you're suggesting going down? I'm genuinely interested here, I'm not having a dig.
Hi John,
Arguably it's not the end-of-the-world to go though CNAMEs. If it works for you, then don't let me deter you.
But you do realize that it requires the client to have logic to see "ah, the record returned is a CNAME so let's use this name to build the principal instead"? And I would not be surprised to see some scenario where the client actually tried to get a ticket with the supplied name and than fell-back to using the CNAME in which case you have extra DNS and Kerberos traffic. If at some point someone wants to use another HTTP client from a cron job or some Java app, is that client going to handle the CNAME correctly?
What happends if the client application needs the original princpal name for some reason? It will get what the CNAME points to. That could be weird for the app or a developer. And then if you move the website to another server the principal name is now suddenly different?
CNAMEs in general are dubious. And not just for Kerberos.
Also short names are dubios. Is it a NetBIOS name or does the client have a proper DNS search suffix configured? And in the later case it takes extra DNS queries to get the name.
Why have all this extra indirection on top of an already fickle protocol?
Regarding PTR records, I don't think kerberos would have any problem without them. Actually I seem to recall that once upon a time old Kerberos clients used to automatically try PTR lookups to get the primary hostname first but that practice has long since been ruled bad and clients no longer do it. That might be what you're thinking of.
If you're going to have user's trying to use a site with a certain hostname, IMO you should just have a proper A and PTR records. Yeah, it can work without. But not always and it can be a burden for users to figure out the problem and for admins to add the necessary SPN, A and PTR records, get rid of the CNAME, wait for the cache to clear, purge all the old tickets, etc.
Mike
On Fri, 18 Mar 2011, Michael B Allen wrote:
Hi John,
Arguably it's not the end-of-the-world to go though CNAMEs. If it works for you, then don't let me deter you.
Indeed it does, and it was the only way I could see you /could/ do this. Especially if you're not a domain admin. I'm still not clear your method /can/ work. Are you saying you've done it this way and it does? With multiple A records if I do:
ssh 10.0.0.1
Which kerberos credential will the remote side use?
With the CNAME approach, there's no ambiguity.
But you do realize that it requires the client to have logic to see "ah, the record returned is a CNAME so let's use this name to build the principal instead"?
MIT kerberos suggests it uses this to figure out the SPN:
gethostbyaddr(gethostbyname(host))
Surely that wouldn't care how I'd done it? That requires the PTR record, and that it points back to the name of the pricipal you want to use. With multiple PTR records to the same IP I can't work out how this is going to end. Will it round-robin and simply work because the remote end has all of them?
Clearly sometimes there's not even a domain name to start with. You can quite merrily do "ssh 10.0.0.1" and get a kerberised login. With multiple PTRs to a single IP, I can only assume you'll round-robin through the credentials. So when you add an A and PTR record and forget to add the principal, kerberos logins will fail 1/N of the time.
And I would not be surprised to see some scenario where the client actually tried to get a ticket with the supplied name and than fell-back to using the CNAME in which case you have extra DNS and Kerberos traffic. If at some point someone wants to use another HTTP client from a cron job or some Java app, is that client going to handle the CNAME correctly?
As far as I can tell, the client will be blissfully unaware.
What happends if the client application needs the original princpal name for some reason? It will get what the CNAME points to. That could be weird for the app or a developer. And then if you move the website to another server the principal name is now suddenly different?
Yes. But why would the developer care about the service principal name? It's not often you're that introspective, you're normally more interested in the client's principal.
CNAMEs in general are dubious. And not just for Kerberos.
I think that's a little harsh. CNAMEs seem to be unloved for reasons I'm not fully convinced by. What is so bad about CNAMEs?
Also short names are dubios. Is it a NetBIOS name or does the client have a proper DNS search suffix configured? And in the later case it takes extra DNS queries to get the name.
AD always creates both short and FQDN forms of principals, I assume it's as you guessed because of a NetBIOSism, or because it's a cruft that can often fix broken setups. I don't know, I only ever use the FQDN form.
Why have all this extra indirection on top of an already fickle protocol?
I haven't actually found kerberos to be too fickle at all.
Regarding PTR records, I don't think kerberos would have any problem without them.
As far as I knew MIT kerberos doesn't work at all without them, due to the way it calculates service principals. Certainly if you have a pair of A records for the same IP, and the PTR record points to the name that doesn't match the service principal it all will not work.
Actually I seem to recall that once upon a time old Kerberos clients used to automatically try PTR lookups to get the primary hostname first but that practice has long since been ruled bad and clients no longer do it. That might be what you're thinking of.
AD 2003 doesn't work correctly if the PTR record doesn't match the service principal, even if there's also an A record that does. As far as I'm aware the same is true for MIT kerberos.
If you're going to have user's trying to use a site with a certain hostname, IMO you should just have a proper A and PTR records. Yeah, it can work without. But not always and it can be a burden for users to figure out the problem and for admins to add the necessary SPN, A and PTR records, get rid of the CNAME, wait for the cache to clear, purge all the old tickets, etc.
But are you suggesting multiple PTR records for the same IP? That's normally considered bad DNS practice isn't it, never mind kerberos practice?
I'm just not sure I see any advantage in using multiple A and PTR records.
Thanks for the discussion though, it's really not something I'd overly thought about before. There never seems to be enough googlable advice on using kerberos out there.
jh
On Fri, Mar 18, 2011 at 6:25 AM, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
On Fri, 18 Mar 2011, Michael B Allen wrote:
Hi John,
Arguably it's not the end-of-the-world to go though CNAMEs. If it works for you, then don't let me deter you.
Indeed it does, and it was the only way I could see you /could/ do this. Especially if you're not a domain admin. I'm still not clear your method /can/ work. Are you saying you've done it this way and it does? With multiple A records if I do:
ssh 10.0.0.1
Which kerberos credential will the remote side use?
With the CNAME approach, there's no ambiguity.
But you do realize that it requires the client to have logic to see "ah, the record returned is a CNAME so let's use this name to build the principal instead"?
MIT kerberos suggests it uses this to figure out the SPN:
gethostbyaddr(gethostbyname(host))
Hi John,
Actually I think this practice is now considered poor behavior. I look at a lot of packet captures and I don't recall seeing PTR lookups. At least not from Windows clients. Also I recall there was a discussion about this on the Kerberos list and the verdict from one of the MIT chaps was that it was actually not desirable to use PTR lookups.
Surely that wouldn't care how I'd done it? That requires the PTR record, and that it points back to the name of the pricipal you want to use. With multiple PTR records to the same IP I can't work out how this is going to end. Will it round-robin and simply work because the remote end has all of them?
True. You cannot have multiple PTR records for an IP. I did not mean to suggest that you could.
Clearly sometimes there's not even a domain name to start with. You can quite merrily do "ssh 10.0.0.1" and get a kerberised login. With multiple PTRs to a single IP, I can only assume you'll round-robin through the credentials. So when you add an A and PTR record and forget to add the principal, kerberos logins will fail 1/N of the time.
Well you should not use an IP at all really because IPs change. But if the client is remotely sophisticated it should be able to do a PTR lookup and try that name.
And I would not be surprised to see some scenario where the client actually tried to get a ticket with the supplied name and than fell-back to using the CNAME in which case you have extra DNS and Kerberos traffic. If at some point someone wants to use another HTTP client from a cron job or some Java app, is that client going to handle the CNAME correctly?
As far as I can tell, the client will be blissfully unaware.
What happends if the client application needs the original princpal name for some reason? It will get what the CNAME points to. That could be weird for the app or a developer. And then if you move the website to another server the principal name is now suddenly different?
Yes. But why would the developer care about the service principal name? It's not often you're that introspective, you're normally more interested in the client's principal.
For very simple scenarios you probably would not care. But here could be numerous reasons for wanting to know the name of the service you're talking to.
CNAMEs in general are dubious. And not just for Kerberos.
I think that's a little harsh. CNAMEs seem to be unloved for reasons I'm not fully convinced by. What is so bad about CNAMEs?
Also short names are dubios. Is it a NetBIOS name or does the client have a proper DNS search suffix configured? And in the later case it takes extra DNS queries to get the name.
AD always creates both short and FQDN forms of principals, I assume it's as you guessed because of a NetBIOSism, or because it's a cruft that can often fix broken setups. I don't know, I only ever use the FQDN form.
Why have all this extra indirection on top of an already fickle protocol?
I haven't actually found kerberos to be too fickle at all.
Kerberos requires that clients have access to the KDC, it depends heavily on DNS, stale tickets can cause cryptic errors until clients purge credential caches, etc. It's a great protocol conceptually. But in practice it's not super robust. It can be difficult to track down the source of issues. We had a customer who couldn't figure a Kerberos issue for days. They had checked the time on the machine and thought it was correct but it was actually off by exactly 12 hours. Meaning it was set to like 2:43 AM when it was really 2:43 PM.
Regarding PTR records, I don't think kerberos would have any problem without them.
As far as I knew MIT kerberos doesn't work at all without them, due to the way it calculates service principals. Certainly if you have a pair of A records for the same IP, and the PTR record points to the name that doesn't match the service principal it all will not work.
My business is all about integrating non-Windows systems into WIndows environments so I don't look at what MIT is doing much. Windows clients do not use PTR lookups to build SPNs so our code does not either.
Actually I seem to recall that once upon a time old Kerberos clients used to automatically try PTR lookups to get the primary hostname first but that practice has long since been ruled bad and clients no longer do it. That might be what you're thinking of.
AD 2003 doesn't work correctly if the PTR record doesn't match the service principal, even if there's also an A record that does. As far as I'm aware the same is true for MIT kerberos.
An HTTP client can authenticate with any principal in the service keytab and only one of their hostnames is going to have a PTR record. So I'm not sure I understand your claim here.
If you're going to have user's trying to use a site with a certain hostname, IMO you should just have a proper A and PTR records. Yeah, it can work without. But not always and it can be a burden for users to figure out the problem and for admins to add the necessary SPN, A and PTR records, get rid of the CNAME, wait for the cache to clear, purge all the old tickets, etc.
But are you suggesting multiple PTR records for the same IP? That's normally considered bad DNS practice isn't it, never mind kerberos practice?
I'm just not sure I see any advantage in using multiple A and PTR records.
True. True. I didn't mean to suggest that you have multiple PTR records for the same IP. Actually it's impossible because the record key is like "10.1.168.192.in-addr.arpa" so obviously there can be only one.
Mike
On Fri, 18 Mar 2011, Michael B Allen wrote:
True. You cannot have multiple PTR records for an IP. I did not mean to suggest that you could.
Not saying you are wrong here, but have you an RFC reference to this effect? We previously held this belief from our prior practice, but cannot find a clear prohibition of such. As such our DNS zonefile management code does not enforce such a limitation presently
Considering the issue from the other side, there is nothing that requires simplicity if implementation of a client that says it can accept only a single PTR, rather than an array of replies and then walking the reverses
-- Russ herrold
On Fri, Mar 18, 2011 at 2:58 PM, R P Herrold herrold@owlriver.com wrote:
On Fri, 18 Mar 2011, Michael B Allen wrote:
True. You cannot have multiple PTR records for an IP. I did not mean to suggest that you could.
Not saying you are wrong here, but have you an RFC reference to this effect? We previously held this belief from our prior practice, but cannot find a clear prohibition of such. As such our DNS zonefile management code does not enforce such a limitation presently
Considering the issue from the other side, there is nothing that requires simplicity if implementation of a client that says it can accept only a single PTR, rather than an array of replies and then walking the reverses
Hello R,
No, I do not have a citation and theoretically having multiple PTR records for an IP might actually be quite reasonable. However, I would imagine it would be fairly limited to things like clusters or servers that should have the outward appearance of being identical. For something like kerberos with HTTP servers doing virtual hosting (like what John and I have been discussing in this thread), I suspect multiple PTRs for the web server would create quite a mess.
Mike
On Fri, Mar 18, 2011 at 2:36 PM, Michael B Allen ioplex@gmail.com wrote:
On Fri, Mar 18, 2011 at 6:25 AM, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
Surely that wouldn't care how I'd done it? That requires the PTR record, and that it points back to the name of the pricipal you want to use. With multiple PTR records to the same IP I can't work out how this is going to end. Will it round-robin and simply work because the remote end has all of them?
True. You cannot have multiple PTR records for an IP. I did not mean to suggest that you could.
You *shouldn't*. But there's nothing in Bind or ther other common DNS architectures that enforces this practice, and I'm afraid that it's quite common for poorly configured systems that support dynamic DNS to permit this. It's why I give admins of Active Directory based systems such a hard time and try to insist that they allow me at least one location that I can do actual zone transfers, to detect multiple PTR's for one IP address, or the same hostname having multiple PTR's that point to it.
The old "mkrdns" tool used to be fabulous for detecting, configuring, and correctly handling multiple A records and notifying you of their existence: I still appreciate its simplicity and robustness.
Nico Kadel-Garcia nkadel@gmail.com
Clearly sometimes there's not even a domain name to start with. You can quite merrily do "ssh 10.0.0.1" and get a kerberised login. With multiple PTRs to a single IP, I can only assume you'll round-robin through the credentials. So when you add an A and PTR record and forget to add the principal, kerberos logins will fail 1/N of the time.
Well you should not use an IP at all really because IPs change. But if the client is remotely sophisticated it should be able to do a PTR lookup and try that name.
And I would not be surprised to see some scenario where the client actually tried to get a ticket with the supplied name and than fell-back to using the CNAME in which case you have extra DNS and Kerberos traffic. If at some point someone wants to use another HTTP client from a cron job or some Java app, is that client going to handle the CNAME correctly?
As far as I can tell, the client will be blissfully unaware.
What happends if the client application needs the original princpal name for some reason? It will get what the CNAME points to. That could be weird for the app or a developer. And then if you move the website to another server the principal name is now suddenly different?
Yes. But why would the developer care about the service principal name? It's not often you're that introspective, you're normally more interested in the client's principal.
For very simple scenarios you probably would not care. But here could be numerous reasons for wanting to know the name of the service you're talking to.
CNAMEs in general are dubious. And not just for Kerberos.
I think that's a little harsh. CNAMEs seem to be unloved for reasons I'm not fully convinced by. What is so bad about CNAMEs?
Also short names are dubios. Is it a NetBIOS name or does the client have a proper DNS search suffix configured? And in the later case it takes extra DNS queries to get the name.
AD always creates both short and FQDN forms of principals, I assume it's as you guessed because of a NetBIOSism, or because it's a cruft that can often fix broken setups. I don't know, I only ever use the FQDN form.
Why have all this extra indirection on top of an already fickle protocol?
I haven't actually found kerberos to be too fickle at all.
Kerberos requires that clients have access to the KDC, it depends heavily on DNS, stale tickets can cause cryptic errors until clients purge credential caches, etc. It's a great protocol conceptually. But in practice it's not super robust. It can be difficult to track down the source of issues. We had a customer who couldn't figure a Kerberos issue for days. They had checked the time on the machine and thought it was correct but it was actually off by exactly 12 hours. Meaning it was set to like 2:43 AM when it was really 2:43 PM.
Regarding PTR records, I don't think kerberos would have any problem without them.
As far as I knew MIT kerberos doesn't work at all without them, due to the way it calculates service principals. Certainly if you have a pair of A records for the same IP, and the PTR record points to the name that doesn't match the service principal it all will not work.
My business is all about integrating non-Windows systems into WIndows environments so I don't look at what MIT is doing much. Windows clients do not use PTR lookups to build SPNs so our code does not either.
Actually I seem to recall that once upon a time old Kerberos clients used to automatically try PTR lookups to get the primary hostname first but that practice has long since been ruled bad and clients no longer do it. That might be what you're thinking of.
AD 2003 doesn't work correctly if the PTR record doesn't match the service principal, even if there's also an A record that does. As far as I'm aware the same is true for MIT kerberos.
An HTTP client can authenticate with any principal in the service keytab and only one of their hostnames is going to have a PTR record. So I'm not sure I understand your claim here.
If you're going to have user's trying to use a site with a certain hostname, IMO you should just have a proper A and PTR records. Yeah, it can work without. But not always and it can be a burden for users to figure out the problem and for admins to add the necessary SPN, A and PTR records, get rid of the CNAME, wait for the cache to clear, purge all the old tickets, etc.
But are you suggesting multiple PTR records for the same IP? That's normally considered bad DNS practice isn't it, never mind kerberos practice?
I'm just not sure I see any advantage in using multiple A and PTR records.
True. True. I didn't mean to suggest that you have multiple PTR records for the same IP. Actually it's impossible because the record key is like "10.1.168.192.in-addr.arpa" so obviously there can be only one.
Mike
-- Michael B Allen Java Active Directory Integration http://www.ioplex.com/
Thanks for the discussion though, it's really not something I'd overly thought about before. There never seems to be enough googlable advice on using kerberos out there.
jh _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Fri, 18 Mar 2011, Michael B Allen wrote:
Hi John,
Actually I think this practice is now considered poor behavior. I look at a lot of packet captures and I don't recall seeing PTR lookups. At least not from Windows clients. Also I recall there was a discussion about this on the Kerberos list and the verdict from one of the MIT chaps was that it was actually not desirable to use PTR lookups.
And I think you've probably nailed my slightly blinkered view of all this. I'm too used to dealing with MIT kerberos linux clients interacting with a 2003/2008 windows AD domain. It'll be client requirements for the PTR records that I'm affected by, not anything that's part of the AD side.
True. You cannot have multiple PTR records for an IP. I did not mean to suggest that you could.
You can, but it's a bad idea.
Well you should not use an IP at all really because IPs change. But if the client is remotely sophisticated it should be able to do a PTR lookup and try that name.
I think it's just in the multi-record case this becomes a bit grim, as your PTR record can only sanely return a single A record. Not that I guess that /really/ matters.
For very simple scenarios you probably would not care. But here could be numerous reasons for wanting to know the name of the service you're talking to.
I guess. But then in some ways it's only the same as if you'd changed your web servers and created a new subdomain to handle ssl request. Clients shouldn't get hung up on details.
Kerberos requires that clients have access to the KDC, it depends heavily on DNS, stale tickets can cause cryptic errors until clients purge credential caches, etc. It's a great protocol conceptually. But in practice it's not super robust. It can be difficult to track down the source of issues. We had a customer who couldn't figure a Kerberos issue for days. They had checked the time on the machine and thought it was correct but it was actually off by exactly 12 hours. Meaning it was set to like 2:43 AM when it was really 2:43 PM.
Sure, it's time fussy. But all in, large Active Directory domains tick along pretty well. Anything that encourages proper ntp usage is a good thing. It's the sort of thing the windows world seems somewhat well adapted to. Machine doesn't think you're a member of a group you've been recently added to? Log out and log back in again and it'll be fine...
My business is all about integrating non-Windows systems into WIndows environments so I don't look at what MIT is doing much. Windows clients do not use PTR lookups to build SPNs so our code does not either.
I see. I think my focus was more on getting the kerberos clients that are out there working as happily as possible with what we've got, so I've got a slightly different angle.
AD 2003 doesn't work correctly if the PTR record doesn't match the service principal, even if there's also an A record that does. As far as I'm aware the same is true for MIT kerberos.
An HTTP client can authenticate with any principal in the service keytab and only one of their hostnames is going to have a PTR record. So I'm not sure I understand your claim here.
Two A records, with PTR record pointing to the A record that didn't have a service principal defined. MIT client tries to use valid A record, MIT client rejects the connection as it can't get a service principal for the PTR directed A record. I'm not saying it *should* do this...
In AD, the machine's only going to have service principals for the FQDN that matches the machine name it was joined to the domain with. Creating these additionaly service principals I think is something you can't trivially do without being a domain admin, or perhaps creating dummy machine records. If you're using AD for DNS as well, I think that could end up being a bit exciting.
jh
On Sat, Mar 19, 2011 at 4:28 AM, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
An HTTP client can authenticate with any principal in the service keytab and only one of their hostnames is going to have a PTR record. So I'm not sure I understand your claim here.
Two A records, with PTR record pointing to the A record that didn't have a service principal defined. MIT client tries to use valid A record, MIT client rejects the connection as it can't get a service principal for the PTR directed A record. I'm not saying it *should* do this...
In AD, the machine's only going to have service principals for the FQDN that matches the machine name it was joined to the domain with. Creating these additionaly service principals I think is something you can't trivially do without being a domain admin, or perhaps creating dummy machine records. If you're using AD for DNS as well, I think that could end up being a bit exciting.
Hi John,
You would not have to create "dummy" machine records. The servicePrincipalName attribute on an AD account is multi-valued and clients can request and get a ticket for ANY principal in that list. So you only need one account.
And you do not need special permissions if you have an existing keytab because you can use the keytab to authenticate with AD and add servicePrincipalName values to the account itself. At least in theory you can. I don't know if Samba's routine for adding HTTP SPNs is smart enough to know that it needs to not just add servicePrincipalName values but that it will also need to rebuild the keytab.
And of course you do not have to use the Samba keytab at all really. In fact, if you're doing a lot of HTTP virtual hosting (which is really what we're talking about) you're probably better off just creating a separate service account, adding SPNs using setspn.exe and then build a keytab with principals for all of the SPNs with some tool like ktutil (ktpass.exe will not work though because it only sets one HTTP principal last I checked - it's a useless program).
In our Plexcel product we have a routine that just queries AD for the latest KVNO and servicePrincipalName attribute and then generates a keytab with an entries for each servicePrincipalName value:
http://www.ioplex.com/api/plexcel_gen_service_keytab.html
This is largely used by the "setup" program of the Plexcel software for itself but it would be no less useful for just about anyting that needs a keytab from AD.
Mike
On Tue, 22 Mar 2011, Michael B Allen wrote:
Hi John,
You would not have to create "dummy" machine records. The servicePrincipalName attribute on an AD account is multi-valued and clients can request and get a ticket for ANY principal in that list. So you only need one account.
And you do not need special permissions if you have an existing keytab because you can use the keytab to authenticate with AD and add servicePrincipalName values to the account itself. At least in theory you can. I don't know if Samba's routine for adding HTTP SPNs is smart enough to know that it needs to not just add servicePrincipalName values but that it will also need to rebuild the keytab.
Yes, but using the machine principal you're able to request any number of service principals that are SERVICENAME/<machinename>. For this to work in a virtual hosting environment, you need multiple machine names (since we're talking about making a number of HTTP/<blah> principals). Whilst I accept this is possible, I don't see how you'd do it without being a domain admin. How do I create the records starting from a position of only having the machine credential for the web server, and at best another user credential with rights to create machine objects?
With domain admin rights, I get how your scheme works, although it wasn't a route I'd previously considered.
jh
On Tue, Mar 22, 2011 at 5:55 AM, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
On Tue, 22 Mar 2011, Michael B Allen wrote:
Hi John,
You would not have to create "dummy" machine records. The servicePrincipalName attribute on an AD account is multi-valued and clients can request and get a ticket for ANY principal in that list. So you only need one account.
And you do not need special permissions if you have an existing keytab because you can use the keytab to authenticate with AD and add servicePrincipalName values to the account itself. At least in theory you can. I don't know if Samba's routine for adding HTTP SPNs is smart enough to know that it needs to not just add servicePrincipalName values but that it will also need to rebuild the keytab.
Yes, but using the machine principal you're able to request any number of service principals that are SERVICENAME/<machinename>. For this to work in a virtual hosting environment, you need multiple machine names (since we're talking about making a number of HTTP/<blah> principals). Whilst I accept
The "<machinename>" of the principal does NOT have to match the actual machine name. You could create a User object called "alice" with servicePrincipalName values of HTTP/as1.busicorp.local, HTTP/mycomputer.net and HTTP/test1 and requesting tickets for any of those names will work just fine. AD just searches for an account with a servicePrincipalName value that matches the principal requested for the service ticket.
Pedantic note: If you have the same servicePrincipalName value on more than one account, AD will actually choke and not return a ticket at all (because the request is ambiguous), there is no constraint in AD to stop people from accidentally adding the same SPN to multiple accounts and AD will not return any kind of meaningful error about it.
Mike
On Wed, 23 Mar 2011, Michael B Allen wrote:
Yes, but using the machine principal you're able to request any number of service principals that are SERVICENAME/<machinename>. For this to work in a virtual hosting environment, you need multiple machine names (since we're talking about making a number of HTTP/<blah> principals). Whilst I accept
The "<machinename>" of the principal does NOT have to match the actual machine name. You could create a User object called "alice" with servicePrincipalName values of HTTP/as1.busicorp.local, HTTP/mycomputer.net and HTTP/test1 and requesting tickets for any of those names will work just fine. AD just searches for an account with a servicePrincipalName value that matches the principal requested for the service ticket.
Pedantic note: If you have the same servicePrincipalName value on more than one account, AD will actually choke and not return a ticket at all (because the request is ambiguous), there is no constraint in AD to stop people from accidentally adding the same SPN to multiple accounts and AD will not return any kind of meaningful error about it.
Sure, but if you're not a domain admin, you've only got a machine principal, and your own principal (which I can use to join machines to the domain). Given those, and *not* a domain admin credential, how do you create those principals?
jh
On Wed, Mar 23, 2011 at 2:35 PM, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
On Wed, 23 Mar 2011, Michael B Allen wrote:
Yes, but using the machine principal you're able to request any number of service principals that are SERVICENAME/<machinename>. For this to work in a virtual hosting environment, you need multiple machine names (since we're talking about making a number of HTTP/<blah> principals). Whilst I accept
The "<machinename>" of the principal does NOT have to match the actual machine name. You could create a User object called "alice" with servicePrincipalName values of HTTP/as1.busicorp.local, HTTP/mycomputer.net and HTTP/test1 and requesting tickets for any of those names will work just fine. AD just searches for an account with a servicePrincipalName value that matches the principal requested for the service ticket.
Pedantic note: If you have the same servicePrincipalName value on more than one account, AD will actually choke and not return a ticket at all (because the request is ambiguous), there is no constraint in AD to stop people from accidentally adding the same SPN to multiple accounts and AD will not return any kind of meaningful error about it.
Sure, but if you're not a domain admin, you've only got a machine principal, and your own principal (which I can use to join machines to the domain). Given those, and *not* a domain admin credential, how do you create those principals?
You do kinit -k with the keytab for the machine account and then an ldap_modify to add servicePrincipalName values for the desired principals. The machine account has permission sufficient to modify itself.
Mike
On Thu, 24 Mar 2011, Michael B Allen wrote:
On Wed, Mar 23, 2011 at 2:35 PM, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
On Wed, 23 Mar 2011, Michael B Allen wrote:
Sure, but if you're not a domain admin, you've only got a machine principal, and your own principal (which I can use to join machines to the domain). Given those, and *not* a domain admin credential, how do you create those principals?
You do kinit -k with the keytab for the machine account and then an ldap_modify to add servicePrincipalName values for the desired principals. The machine account has permission sufficient to modify itself.
But modifying the ldap record for the host doesn't generate the servicePrincipal? How do you get the servicePrincipal into the machine's keytab?
Thanks for taking the time to discuss this by the way,
jh
On Fri, 11 Mar 2011, Dvorkin, Asya wrote:
[root@myserver conf]# klist -k Keytab name: FILE:/etc/krb5.keytab KVNO Principal
2 host/myserver.server.com@CORE.HOST.EDU 2 host/rmyserver.server.com@CORE.HOST.EDU 2 host/myserver.server.com@CORE.HOST.EDU 2 host/myserver@CORE.HOST.EDU 2 host/myserver@CORE.HOST.EDU 2 host/myserver@CORE.HOST.EDU 2 MYSERVER$@CORE.HOST.EDU 2 MYSERVER$@CORE.HOST.EDU 2 MYSERVER$@CORE.HOST.EDU 2 http/myserver.server.com@CORE.HOST.EDU 2 http/myserver.server.com@CORE.HOST.EDU 2 http/myserver.server.com@CORE.HOSTEDU 2 http/myserver@CORE.HOST.EDU 2 http/myserver@CORE.HOST.EDU 2 http/myserver@CORE.HOST.EDU
So how did you get the point of having this keytab?
My problem is that I am getting an error message in apache logs:
gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information (No principal in keytab matches desired name)
I looked in AD configuration and see that my server does not have appropriate ServicePrincipalName for HTTP (only host).
Then something's wrong there.
net ads status
This *must* agree with your keytab. If it doesn't, let's start again.
net ads keytab flush net ads keytab create net ads keytab ADD HTTP
net ads status klist -k
Make sure you get to a stage where what AD has and what you have agree. Once you've got to that stage, use ktutil to read the system keytab (/etc/krb5.keytab), and delete out the entries you don't want, leaving just the HTTP ones. Write that out to /etc/httpd/conf/krb5.keytab.
Check it's correct:
klist -k /etc/httpd/conf/httpd.keytab
Make sure you've told apache where to find it:
Krb5KeyTab /etc/httpd/conf/httpd.keytab
The example that comes with the RPM in /etc/httpd/conf.d/auth_kerb.conf is a good starting point.
my keytab file: -rw------- 1 apache apache 957 Mar 11 14:31 /etc/httpd/conf/krb5.keytab
I have NO right access to AD server and cannot do much about creating proper keytab file.
Anything else I can do? Am I missing something?
Have a go with that, and see where you get to.
jh
Thank you!
I'm working on it right now and will give my progress report soon :)
Asya
On Mar 14, 2011, at 6:11 AM, John Hodrien wrote:
On Fri, 11 Mar 2011, Dvorkin, Asya wrote:
[root@myserver conf]# klist -k Keytab name: FILE:/etc/krb5.keytab KVNO Principal
2 host/myserver.server.com@CORE.HOST.EDU 2 host/rmyserver.server.com@CORE.HOST.EDU 2 host/myserver.server.com@CORE.HOST.EDU 2 host/myserver@CORE.HOST.EDU 2 host/myserver@CORE.HOST.EDU 2 host/myserver@CORE.HOST.EDU 2 MYSERVER$@CORE.HOST.EDU 2 MYSERVER$@CORE.HOST.EDU 2 MYSERVER$@CORE.HOST.EDU 2 http/myserver.server.com@CORE.HOST.EDU 2 http/myserver.server.com@CORE.HOST.EDU 2 http/myserver.server.com@CORE.HOSTEDU 2 http/myserver@CORE.HOST.EDU 2 http/myserver@CORE.HOST.EDU 2 http/myserver@CORE.HOST.EDU
So how did you get the point of having this keytab?
My problem is that I am getting an error message in apache logs:
gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information (No principal in keytab matches desired name)
I looked in AD configuration and see that my server does not have appropriate ServicePrincipalName for HTTP (only host).
Then something's wrong there.
net ads status
This *must* agree with your keytab. If it doesn't, let's start again.
net ads keytab flush net ads keytab create net ads keytab ADD HTTP
net ads status klist -k
Make sure you get to a stage where what AD has and what you have agree. Once you've got to that stage, use ktutil to read the system keytab (/etc/krb5.keytab), and delete out the entries you don't want, leaving just the HTTP ones. Write that out to /etc/httpd/conf/krb5.keytab.
Check it's correct:
klist -k /etc/httpd/conf/httpd.keytab
Make sure you've told apache where to find it:
Krb5KeyTab /etc/httpd/conf/httpd.keytab
The example that comes with the RPM in /etc/httpd/conf.d/auth_kerb.conf is a good starting point.
my keytab file: -rw------- 1 apache apache 957 Mar 11 14:31 /etc/httpd/conf/krb5.keytab
I have NO right access to AD server and cannot do much about creating proper keytab file.
Anything else I can do? Am I missing something?
Have a go with that, and see where you get to.
jh _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
David Brian Chait -
Dvorkin, Asya -
John Hodrien -
Michael B Allen -
Nico Kadel-Garcia -
R P Herrold