[Freeipa-users] Recomendations on multi-domain environments
Hi there! This is my situation. I have some users of my main domain cica.es. But I also maintain a database of users of others domain, ie example.es. I can apply most of FreeIPA configuration to cica.es users: access to hosts, groups, policies, roles, etc.. But users of example.es are dummy users, who just have an LDAP account in order to use virtual mailboxes in Postfix/Dovecot. Do anyone have any advice on how handle this situation? I see some options: * create a second FreeIPA server, each to handle his own domain. * get the main FreeIPA server to handle two complete different LDAP tree (with different root DNs, don't know if possible). * integrate example.es users into specific groups, prefix or something each group and user. We are talking of about 2k users in total (main domain + secondary domain). In addition, there is the possibility to have more than two domains. How FreeIPA handles this multi-domain environment? Best regards. -- Arturo Borrero González Departamento de Seguridad Informática (n...@cica.es) Centro Informático Científico de Andalucía (CICA) Avda. Reina Mercedes s/n - 41012 - Sevilla (Spain) Tfno.: +34 955 056 600 / FAX: +34 955 056 650 Consejería de Economía, Innovación, Ciencia y Empleo Junta de Andalucía smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Recomendations on multi-domain environments
On Wed, Sep 18, 2013 at 9:40 PM, Arturo Borrero aborr...@cica.es wrote: Hi there! This is my situation. I have some users of my main domain cica.es. But I also maintain a database of users of others domain, ie example.es. I can apply most of FreeIPA configuration to cica.es users: access to hosts, groups, policies, roles, etc.. But users of example.es are dummy users, who just have an LDAP account in order to use virtual mailboxes in Postfix/Dovecot. Do anyone have any advice on how handle this situation? I see some options: * create a second FreeIPA server, each to handle his own domain. * get the main FreeIPA server to handle two complete different LDAP tree (with different root DNs, don't know if possible). * integrate example.es users into specific groups, prefix or something each group and user. We are talking of about 2k users in total (main domain + secondary domain). In addition, there is the possibility to have more than two domains. How FreeIPA handles this multi-domain environment? Best regards. -- If your second domain is just for LDAP (this is a little similar to what I did). It's not a fluid as you end up limited to the two domains.. . Keep the FreeIPA for hosting cica.es to do your host polices etc. Then on your virtual mailboxes two options we did was either: - Change the default mail atribute in FreeIPA settings so a user would have user.n...@example.es rather than user.dom...@cica.es in their mail attribute then have the LDAP config lookup that rather than username - The other simple alternative is simply have LDAP search the username and append @example.es or not at all. HTH ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] ipa and puppet
Hi, we are testing freeipa and we are wonder if anyone knows how to edit ldap tree (or what to do) to be able to store puppet nodes in ipa's ldap. I found this RFE on redhat bugzilla, but I do not understand it so much. https://bugzilla.redhat.com/show_bug.cgi?id=805368 Thank you for any hint. Jakub Bittner ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] ipa-client auth with windomain account
Hi, Do I need network access to ports from the ipa-client to the server- windows for authentication with windomain accounts? ipa-server fedora19 ipa-client fedora19 winserver win2012 the ipa-client is located in another network within the network ipa-server, ipa-client and windows-server authentication works to the ipa-client: #id windomainuser@windomain id: windomainuser@windomain: No such user please tell me what I'm doing wrong ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa and puppet
Jakub Bittner wrote: Hi, we are testing freeipa and we are wonder if anyone knows how to edit ldap tree (or what to do) to be able to store puppet nodes in ipa's ldap. I found this RFE on redhat bugzilla, but I do not understand it so much. https://bugzilla.redhat.com/show_bug.cgi?id=805368 Thank you for any hint. I guess it depends on what sort of integration you're looking to do. If the data is independent, sure you can store it in the IPA ldap server, we just recommend storing it in a separate container, separate from the IPA data. If you want to augment existing entries then that is possible, just a bit more complicated. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Elliptic curves with the CA
I do not have a valid support contract, or other contracts with RedHat. Doesn't that stop me from opening proper RFE ticket? In any case, my interest was this time solely for evaluation purposes. If I were actively choosing an integrated identity management product, I might not choose Freeipa because it takes the longevity of the product and the development stance (lack of roadmap?) into question. RSA is slowly getting into slippery slope, because it really isn't about what it's worth today. When you protect something with a cryptographic algorithm you have to take account for how long certain types of data will be stored, and factor that time frame in. Increasing the key sizes will not be solution, because several embedded devices such as VPN products, smartcards and RFID devices will start failing pretty fast after 1024-2048 bit keys. ECC was designed to solve some of these issues; it's important development not mostly because of security today but because it will scale better up (it was designed to be implementable better on hardware), and the key sizes start from nicer point of security vs size. So it's the feature that would future proof the CA. At this moment there is available ECC support on some products on all the areas such as smart cards, so the products not having that option out of the box will start basically losing in the competition. I'm not trying to make a technical point here (if I made some minor error there, sorry) but a managerial, and from product management viewpoint. ECC must be on the feature set, or the CA features will be discarded in the future by potential users. That means the Freeipa as a whole might not be selected for some projects. Plus, it doesn't really hurt having ECC in. :) IPA uses NSS, NSS support of ECC algorithms is very fresh, we have not looked at this area yet. I suspect it would require changes in Dogtag first. Would be best if you can file and RFE ticket, then we would be able to follow up. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] slapi-nis bypass Password Policies
Hi, We have a client server connected to the IPA server using NIS. It's working well but we have a service running at client server that doesn't handle the password expiration properly. Is it possible to bypass the Password Policies from this client server? Thanks! ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Elliptic curves with the CA
On 09/18/2013 11:53 AM, mees virk wrote: I do not have a valid support contract, or other contracts with RedHat. Doesn't that stop me from opening proper RFE ticket? Not at all - https://fedorahosted.org/freeipa/newticket - depending on what you mean by proper. In any case, my interest was this time solely for evaluation purposes. If I were actively choosing an integrated identity management product, I might not choose Freeipa because it takes the longevity of the product and the development stance (lack of roadmap?) into question. RSA is slowly getting into slippery slope, because it really isn't about what it's worth today. When you protect something with a cryptographic algorithm you have to take account for how long certain types of data will be stored, and factor that time frame in. Increasing the key sizes will not be solution, because several embedded devices such as VPN products, smartcards and RFID devices will start failing pretty fast after 1024-2048 bit keys. ECC was designed to solve some of these issues; it's important development not mostly because of security today but because it will scale better up (it was designed to be implementable better on hardware), and the key sizes start from nicer point of security vs size. So it's the feature that would future proof the CA. At this moment there is available ECC support on some products on all the areas such as smart cards, so the products not having that option out of the box will start basically losing in the competition. I'm not trying to make a technical point here (if I made some minor error there, sorry) but a managerial, and from product management viewpoint. ECC must be on the feature set, or the CA features will be discarded in the future by potential users. That means the Freeipa as a whole might not be selected for some projects. Plus, it doesn't really hurt having ECC in. :) IPA uses NSS, NSS support of ECC algorithms is very fresh, we have not looked at this area yet. I suspect it would require changes in Dogtag first. Would be best if you can file and RFE ticket, then we would be able to follow up. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Elliptic curves with the CA
On 09/18/2013 01:53 PM, mees virk wrote: I do not have a valid support contract, or other contracts with RedHat. Doesn't that stop me from opening proper RFE ticket? In any case, my interest was this time solely for evaluation purposes. If I were actively choosing an integrated identity management product, I might not choose Freeipa because it takes the longevity of the product and the development stance (lack of roadmap?) into question. RSA is slowly getting into slippery slope, because it really isn't about what it's worth today. When you protect something with a cryptographic algorithm you have to take account for how long certain types of data will be stored, and factor that time frame in. Increasing the key sizes will not be solution, because several embedded devices such as VPN products, smartcards and RFID devices will start failing pretty fast after 1024-2048 bit keys. ECC was designed to solve some of these issues; it's important development not mostly because of security today but because it will scale better up (it was designed to be implementable better on hardware), and the key sizes start from nicer point of security vs size. So it's the feature that would future proof the CA. At this moment there is available ECC support on some products on all the areas such as smart cards, so the products not having that option out of the box will start basically losing in the competition. I'm not trying to make a technical point here (if I made some minor error there, sorry) but a managerial, and from product management viewpoint. ECC must be on the feature set, or the CA features will be discarded in the future by potential users. That means the Freeipa as a whole might not be selected for some projects. Plus, it doesn't really hurt having ECC in. :) Yes we understand these issues. IPA is designed for longevity. EC is still very new, there are many components on which IPA depends which have to gain EC support before IPA can offer it, that is work which is actively in progress. There are still some intellectual property questions which are under consideration with respect to EC. And there has to be demand to support EC in IPA otherwise other RFE's and bug's will take precedence. The short story is EC is emerging, we comprehend it's value and it will almost certainly appear at some point in IPA in some form. Please do file an RFE. -- John ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
