Re: [Freeipa-users] kerberos principals for service accounts (cn=etc, cn=sysaccounts)
On Fri, Jun 15, 2012 at 6:09 AM, Simo Sorce s...@redhat.com wrote: On Fri, 2012-06-15 at 00:10 -0700, Stephen Ingram wrote: Is it possible for accounts in cn=etc,cn=sysaccounts to have kerberos principals or must you use the cn=accounts,cn=users container? I'm thinking this for script-authenticated machine accounts (might be of form user-hostname@REALM or user/hostname@REALM) that need to authenticate to another machine and just a way to separate them from the regular user accounts in cn=accounts,cn=users. If you need to authenticate machines you probably want to use the machine keytab in /etc/krb5.keytab which contains a host/fqdn@REALM principal. The principal is stored in cn=computers,cn=accounts in the computer object if the machine is joined to IPA. for machines you do not want to join or if you want to use a different service principal name you should create a new service principal with 'ipa service-add' which will create a principal object in cn=services user-hostname or user/hostname are not common choices, while kerberos does not enforce any particular convention on names you usually want to use service/fqdn@REALm convention. Where 'service' is the service name. Many services already have conventions for the principal name (for example HTTP/fqdn@REALM for http servers). If your scripts are arbitrary you may decide to create your own script principal (useful if you want to assign special ACIs to it in IPA as you can reference the service account under cn=services in ACIs in theory. I couldn't agree more. Here's the situation though. I'm trying to use IPA for a Cyrus IMAP Murder configuration. This involves machine-to-machine authentication, but it's not really the machine, it's a process on the machine. It's a process client authenticating itself to a process server. The client constantly authenticates using a script to obtain keys from a keytab. The server is authenticated when the client connects to it. I was thinking like you are suggesting, to use service principals, but I'm being told that user principals are the way to go on the client end of things. Not wanting to mix service users in with my regular users, I thought about putting them in sysaccounts. I should probably take this up on the kerberos list, but I was trying to do this within the constructs of IPA. I've read that kerberos is indifferent to user vs service principals. Is this true also of IPA besides the organization of the keys? Steve ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] kerberos principals for service accounts (cn=etc, cn=sysaccounts)
On Tue, 2012-06-19 at 09:28 -0700, Stephen Ingram wrote: On Fri, Jun 15, 2012 at 6:09 AM, Simo Sorce s...@redhat.com wrote: On Fri, 2012-06-15 at 00:10 -0700, Stephen Ingram wrote: Is it possible for accounts in cn=etc,cn=sysaccounts to have kerberos principals or must you use the cn=accounts,cn=users container? I'm thinking this for script-authenticated machine accounts (might be of form user-hostname@REALM or user/hostname@REALM) that need to authenticate to another machine and just a way to separate them from the regular user accounts in cn=accounts,cn=users. If you need to authenticate machines you probably want to use the machine keytab in /etc/krb5.keytab which contains a host/fqdn@REALM principal. The principal is stored in cn=computers,cn=accounts in the computer object if the machine is joined to IPA. for machines you do not want to join or if you want to use a different service principal name you should create a new service principal with 'ipa service-add' which will create a principal object in cn=services user-hostname or user/hostname are not common choices, while kerberos does not enforce any particular convention on names you usually want to use service/fqdn@REALm convention. Where 'service' is the service name. Many services already have conventions for the principal name (for example HTTP/fqdn@REALM for http servers). If your scripts are arbitrary you may decide to create your own script principal (useful if you want to assign special ACIs to it in IPA as you can reference the service account under cn=services in ACIs in theory. I couldn't agree more. Here's the situation though. I'm trying to use IPA for a Cyrus IMAP Murder configuration. This involves machine-to-machine authentication, but it's not really the machine, it's a process on the machine. It's a process client authenticating itself to a process server. The client constantly authenticates using a script to obtain keys from a keytab. The server is authenticated when the client connects to it. I was thinking like you are suggesting, to use service principals, but I'm being told that user principals are the way to go on the client end of things. Not wanting to mix service users in with my regular users, I thought about putting them in sysaccounts. I should probably take this up on the kerberos list, but I was trying to do this within the constructs of IPA. I've read that kerberos is indifferent to user vs service principals. Is this true also of IPA besides the organization of the keys? Yes with IPA you can use service principals to initiate context w/o problems. That's why I suggested you use a service principal. AD has a limitation that you must use an actual user to initiate a context, that may be where the suggestion is coming from. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] kerberos principals for service accounts (cn=etc, cn=sysaccounts)
On Tue, Jun 19, 2012 at 6:54 PM, Simo Sorce s...@redhat.com wrote: Yes with IPA you can use service principals to initiate context w/o problems. That's why I suggested you use a service principal. AD has a limitation that you must use an actual user to initiate a context, that may be where the suggestion is coming from. I was just wondering how to to use a service principal coupled to a host in the case of a webapp. We all know those, applications that require binding to a database with a login/pass combo in a file. And was assuming that creating a service principal and then creating a postgresql role with the name of the principal would not work, that I could not login postgresql with that kerberos principal. It turns out it does work! I can create service principals and have them connect to our postgresql servers. Awesome! I need to test this more thouroughly, but this is looking great security wise. Thanks for the tip! :-) -- natxo ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] kerberos principals for service accounts (cn=etc, cn=sysaccounts)
On Fri, 2012-06-15 at 00:10 -0700, Stephen Ingram wrote: Is it possible for accounts in cn=etc,cn=sysaccounts to have kerberos principals or must you use the cn=accounts,cn=users container? I'm thinking this for script-authenticated machine accounts (might be of form user-hostname@REALM or user/hostname@REALM) that need to authenticate to another machine and just a way to separate them from the regular user accounts in cn=accounts,cn=users. If you need to authenticate machines you probably want to use the machine keytab in /etc/krb5.keytab which contains a host/fqdn@REALM principal. The principal is stored in cn=computers,cn=accounts in the computer object if the machine is joined to IPA. for machines you do not want to join or if you want to use a different service principal name you should create a new service principal with 'ipa service-add' which will create a principal object in cn=services user-hostname or user/hostname are not common choices, while kerberos does not enforce any particular convention on names you usually want to use service/fqdn@REALm convention. Where 'service' is the service name. Many services already have conventions for the principal name (for example HTTP/fqdn@REALM for http servers). If your scripts are arbitrary you may decide to create your own script principal (useful if you want to assign special ACIs to it in IPA as you can reference the service account under cn=services in ACIs in theory. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
