Re: [Freeipa-devel] service record conundrum
Rob Crittenden wrote: > Dmitri Pal wrote: >> Rob Crittenden wrote: >>> Here is sort of a tricky problem, need some advice (LONG). >>> >>> When we bootstrap an IPA server we create a number of principals for >>> the server itself. We create a host/, HTTP/ and ldap/ principal using >>> kadmin.local. By using kadmin.local this entry is put into >>> cn=kerberos,dc=example,dc=com. >>> >>> This has the nice side effect of making these records not appear as >>> service entries so they are unmodifiable by anyone, meaning an admin >>> will have a really hard time hosing their server. >>> >>> The downside is that these records do not appear as service entries, >>> so if you search for services on the IPA server you'll get nothing. >>> >> >> How do we search? What base DN we use? One of the solutions might be to >> install these principals as is and only later apply ipaService object >> class to them so that the search for services would find them. Would be >> a bit ugly since as far as I understand these services are in a >> different location in the tree but this approach might be less painfull >> than LDIF and delete and add. >> I hope that we will get the RDN renames pretty soon so that this would >> not be an issue but it might not be soon enough for v2. >> > > We search in the baseDN of the type of object is is, so cn=services, > cn=computers, cn=users, etc. > > We also filter on the objectclasses that should be in that object. > > Searching in 2 places is possible just not something we currently do. > > I'm leaning towards moving the entries, more so since I haven't gotten > any "that is the dumbest idea I've heard all week" responses :-) > > We store a list of the IPA masters in the DIT somewhere, I'll have to > see if I can find a way to maintain protection of the principals using > that. > Will it affect expectations of the KDC on where it searches for its entries? Would we have to also update KDC DAL configuration to search the records in a different place? > rob -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] service record conundrum
Dmitri Pal wrote: Rob Crittenden wrote: Here is sort of a tricky problem, need some advice (LONG). When we bootstrap an IPA server we create a number of principals for the server itself. We create a host/, HTTP/ and ldap/ principal using kadmin.local. By using kadmin.local this entry is put into cn=kerberos,dc=example,dc=com. This has the nice side effect of making these records not appear as service entries so they are unmodifiable by anyone, meaning an admin will have a really hard time hosing their server. The downside is that these records do not appear as service entries, so if you search for services on the IPA server you'll get nothing. How do we search? What base DN we use? One of the solutions might be to install these principals as is and only later apply ipaService object class to them so that the search for services would find them. Would be a bit ugly since as far as I understand these services are in a different location in the tree but this approach might be less painfull than LDIF and delete and add. I hope that we will get the RDN renames pretty soon so that this would not be an issue but it might not be soon enough for v2. We search in the baseDN of the type of object is is, so cn=services, cn=computers, cn=users, etc. We also filter on the objectclasses that should be in that object. Searching in 2 places is possible just not something we currently do. I'm leaning towards moving the entries, more so since I haven't gotten any "that is the dumbest idea I've heard all week" responses :-) We store a list of the IPA masters in the DIT somewhere, I'll have to see if I can find a way to maintain protection of the principals using that. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] service record conundrum
Rob Crittenden wrote: > Here is sort of a tricky problem, need some advice (LONG). > > When we bootstrap an IPA server we create a number of principals for > the server itself. We create a host/, HTTP/ and ldap/ principal using > kadmin.local. By using kadmin.local this entry is put into > cn=kerberos,dc=example,dc=com. > > This has the nice side effect of making these records not appear as > service entries so they are unmodifiable by anyone, meaning an admin > will have a really hard time hosing their server. > > The downside is that these records do not appear as service entries, > so if you search for services on the IPA server you'll get nothing. > How do we search? What base DN we use? One of the solutions might be to install these principals as is and only later apply ipaService object class to them so that the search for services would find them. Would be a bit ugly since as far as I understand these services are in a different location in the tree but this approach might be less painfull than LDIF and delete and add. I hope that we will get the RDN renames pretty soon so that this would not be an issue but it might not be soon enough for v2. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] service record conundrum
Rob Crittenden wrote: Here is sort of a tricky problem, need some advice (LONG). When we bootstrap an IPA server we create a number of principals for the server itself. We create a host/, HTTP/ and ldap/ principal using kadmin.local. By using kadmin.local this entry is put into cn=kerberos,dc=example,dc=com. This has the nice side effect of making these records not appear as service entries so they are unmodifiable by anyone, meaning an admin will have a really hard time hosing their server. The downside is that these records do not appear as service entries, so if you search for services on the IPA server you'll get nothing. Even worse it means you can't request certificates for these services, because they don't exist. Not that one really should since we also generate certificates for these at bootstrap, but we don't store them anywhere because there isn't any place to put them. This also means that we can't track expiration of these. To make things even more fun we have the DS uniqueness plugin configured so there can be no duplication in principal names. Since this is in the RDN of service records we can't even create a bit of a bogus entry to still protect the principals and yet be able to store certificates. Remember too that these records are creating during installation, effectively bootstrapping the real services (httpd, dirsrv), so we have limited options for how to generate them to begin with. One idea I had is to continue to use kadmin.local to create the principals and then move them out of cn=kerberos into cn=services, adding whatever additional data we need. This way we would maintain the principalkeys. Then we'd need to insert the certificates we generate. Unfortunately 389-DS doesn't seem to support newsuperior so I guess we'd have to move it ourselves via delete and re-add. 389 will soon support new superior. But yes, delete then add is the only way to do that at present. If you want to preserve the uuid of the entry, you could dump to ldif, edit the DN to "move" it, then ldif2db back - kind of painful, but would preserve the uuid of the entries. So I'm basically stuck right now. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] service record conundrum
Here is sort of a tricky problem, need some advice (LONG). When we bootstrap an IPA server we create a number of principals for the server itself. We create a host/, HTTP/ and ldap/ principal using kadmin.local. By using kadmin.local this entry is put into cn=kerberos,dc=example,dc=com. This has the nice side effect of making these records not appear as service entries so they are unmodifiable by anyone, meaning an admin will have a really hard time hosing their server. The downside is that these records do not appear as service entries, so if you search for services on the IPA server you'll get nothing. Even worse it means you can't request certificates for these services, because they don't exist. Not that one really should since we also generate certificates for these at bootstrap, but we don't store them anywhere because there isn't any place to put them. This also means that we can't track expiration of these. To make things even more fun we have the DS uniqueness plugin configured so there can be no duplication in principal names. Since this is in the RDN of service records we can't even create a bit of a bogus entry to still protect the principals and yet be able to store certificates. Remember too that these records are creating during installation, effectively bootstrapping the real services (httpd, dirsrv), so we have limited options for how to generate them to begin with. One idea I had is to continue to use kadmin.local to create the principals and then move them out of cn=kerberos into cn=services, adding whatever additional data we need. This way we would maintain the principalkeys. Then we'd need to insert the certificates we generate. Unfortunately 389-DS doesn't seem to support newsuperior so I guess we'd have to move it ourselves via delete and re-add. So I'm basically stuck right now. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
