Re: [Freeipa-users] Logging of Who does What on IPA Server
On 02/14/2013 08:20 AM, Rajnesh Kumar Siwal wrote: IPA is going to be very critical Server for any environment. Do we have proper logging of who as locked whom, Who has created a sudo policy, who has allowed access to whom etc ? Hello Rajnesh, the audit component of IPA collecting and processing audit information is not there yet. There is some information about our future direction in our wiki: http://freeipa.org/page/Roadmap As for logging who did what, you can check existing logs on your IPA server(s) which may have information you need for audit: LDAP access log (LDAP calls): /var/log/dirsrv/slapd-$INST/access http error log (IPA framework calls): /var/log/httpd/error_log Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Granting rights temporarily
Hi, Another interesting recommendation from security is that all granted access (that is exceptional, rather than permanent) should be limited in time from the onset. If this is not possible all granted access needs to be documented and revised regularly. However a system that would automatically revoke access after a certain period is preferred from a security/administrative perspective. (Period to be defined when granting access) This would mean that e.g. sudo-rules, group memberships, etc. could have due dates and that IPA ensures that these rights are revoked in due time. So I was wondering whether this is something that was already discussed as a feature for IPA ? -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Granting rights temporarily
On Thu, Feb 14, 2013 at 10:02 AM, Dag Wieers d...@wieers.com wrote: Hi, Another interesting recommendation from security is that all granted access (that is exceptional, rather than permanent) should be limited in time from the onset. If this is not possible all granted access needs to be documented and revised regularly. However a system that would automatically revoke access after a certain period is preferred from a security/administrative perspective. (Period to be defined when granting access) This would mean that e.g. sudo-rules, group memberships, etc. could have due dates and that IPA ensures that these rights are revoked in due time. So I was wondering whether this is something that was already discussed as a feature for IPA ? +1 -- groet, natxo ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Logging of Who does What on IPA Server
On 14.2.2013 09:49, Martin Kosek wrote: On 02/14/2013 08:20 AM, Rajnesh Kumar Siwal wrote: IPA is going to be very critical Server for any environment. Do we have proper logging of who as locked whom, Who has created a sudo policy, who has allowed access to whom etc ? Hello Rajnesh, the audit component of IPA collecting and processing audit information is not there yet. There is some information about our future direction in our wiki: http://freeipa.org/page/Roadmap As for logging who did what, you can check existing logs on your IPA server(s) which may have information you need for audit: LDAP access log (LDAP calls): /var/log/dirsrv/slapd-$INST/access Also note 389 audit capabilities! http error log (IPA framework calls): /var/log/httpd/error_log -- Petr^2 Spacek ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Granting rights temporarily
On Thu, 14 Feb 2013, Dag Wieers wrote: Hi, Another interesting recommendation from security is that all granted access (that is exceptional, rather than permanent) should be limited in time from the onset. If this is not possible all granted access needs to be documented and revised regularly. However a system that would automatically revoke access after a certain period is preferred from a security/administrative perspective. (Period to be defined when granting access) This would mean that e.g. sudo-rules, group memberships, etc. could have due dates and that IPA ensures that these rights are revoked in due time. So I was wondering whether this is something that was already discussed as a feature for IPA ? Yes, something along these lines was discussed in past. We have three tickets so far in deferred state: https://fedorahosted.org/freeipa/ticket/547 https://fedorahosted.org/freeipa/ticket/548 https://fedorahosted.org/freeipa/ticket/3127 A problem with time-based access management is to consider its locality. Time-limited rules all stored centrally but applied locally and timezones play important role in messing things up. We also wanted to develop solution which would be scalable and easier to integrate with visual tools to edit recurrent events, thus ideas towards use of iCalendar (RFC5545 and RFC5546) format. From FreeIPA perspective application of rules would be done by SSSD and its plugins to various applications (sudo, SELinux enforcement, etc). FreeIPA itself would provide storage and means to edit the rules, both in command line and web UI. We haven't started working on the topic yet because there were (and currently are) numerous other tasks with slightly higher priority. Any contribution in the are is welcomed, even in form of thinking out and writing down feature proposal, based on a template at http://www.freeipa.org/page/Feature_template -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Logging of Who does What on IPA Server
On Thu, 2013-02-14 at 12:50 +0530, Rajnesh Kumar Siwal wrote: IPA is going to be very critical Server for any environment. Do we have proper logging of who as locked whom, Who has created a sudo policy, who has allowed access to whom etc ? You can see this information by querying LDAP directly. The 'creatorsName' attribute holds the identity of the user that created the object. The 'createTimestamp' attribute holds the time at which the object was created. The 'modifiersName' attribute holds the identity of the user that last modified the object. The 'modifyTimestamp' attribute holds the time at which the object was modified. All these attributes are operational, so you normally do not see them unless you explicitly ask for them during an ldap search. Some LDAP browsers allow you to add a list of attributes to ask for explicitly. To see these attributes for a user named foo for example you can run this query: ldapsearch -Y GSSAPI uid=foo creatorsName createTimestamp modifiersName modifyTimestamp add a '*' at the end if you also want to fetch regular attributes. This command assumes you have kerberos credentials (-Y GSSAPI tells ldapsearch to use them to auth to the server). 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] Granting rights temporarily
On Thu, 2013-02-14 at 10:02 +0100, Dag Wieers wrote: Hi, Another interesting recommendation from security is that all granted access (that is exceptional, rather than permanent) should be limited in time from the onset. If this is not possible all granted access needs to be documented and revised regularly. However a system that would automatically revoke access after a certain period is preferred from a security/administrative perspective. (Period to be defined when granting access) This would mean that e.g. sudo-rules, group memberships, etc. could have due dates and that IPA ensures that these rights are revoked in due time. So I was wondering whether this is something that was already discussed as a feature for IPA ? sudo rules have sudoNotBefore sudoNotAfter attributes, so you can limit their validity. User accounts have an expiration time as well. There is no expiration time for groups or group membership, we have not had any previous request or need for this and I am not sure it really is possible to do this for group memberships. I guess we could add an attribute to expire a group, however no client will respect that for now, so it would be a bit pointless if not misguiding. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] SOLVED: Re: Logging of Who does What on IPA Server
Thanks, Simo. It solves my concern, On Thu, Feb 14, 2013 at 7:21 PM, Simo Sorce s...@redhat.com wrote: On Thu, 2013-02-14 at 12:50 +0530, Rajnesh Kumar Siwal wrote: IPA is going to be very critical Server for any environment. Do we have proper logging of who as locked whom, Who has created a sudo policy, who has allowed access to whom etc ? You can see this information by querying LDAP directly. The 'creatorsName' attribute holds the identity of the user that created the object. The 'createTimestamp' attribute holds the time at which the object was created. The 'modifiersName' attribute holds the identity of the user that last modified the object. The 'modifyTimestamp' attribute holds the time at which the object was modified. All these attributes are operational, so you normally do not see them unless you explicitly ask for them during an ldap search. Some LDAP browsers allow you to add a list of attributes to ask for explicitly. To see these attributes for a user named foo for example you can run this query: ldapsearch -Y GSSAPI uid=foo creatorsName createTimestamp modifiersName modifyTimestamp add a '*' at the end if you also want to fetch regular attributes. This command assumes you have kerberos credentials (-Y GSSAPI tells ldapsearch to use them to auth to the server). Simo. -- Simo Sorce * Red Hat, Inc * New York -- Regards, Rajnesh Kumar Siwal ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Granting rights temporarily
On 02/14/2013 06:54 AM, Simo Sorce wrote: On Thu, 2013-02-14 at 10:02 +0100, Dag Wieers wrote: Hi, Another interesting recommendation from security is that all granted access (that is exceptional, rather than permanent) should be limited in time from the onset. If this is not possible all granted access needs to be documented and revised regularly. However a system that would automatically revoke access after a certain period is preferred from a security/administrative perspective. (Period to be defined when granting access) This would mean that e.g. sudo-rules, group memberships, etc. could have due dates and that IPA ensures that these rights are revoked in due time. So I was wondering whether this is something that was already discussed as a feature for IPA ? sudo rules have sudoNotBefore sudoNotAfter attributes, so you can limit their validity. User accounts have an expiration time as well. There is no expiration time for groups or group membership, we have not had any previous request or need for this and I am not sure it really is possible to do this for group memberships. Someone was asking for this in one of the OpenLDAP forums. They want to be able to expire group membership after a certain time. They were going to create a new syntax which would be something like generalizedTime DELIM distinguishedName e.g. dn: cn=temporaryAdminGroup, timedmember: 2013021512Z$uid=richm,.. After 2013021512Z is hit, the value would be removed from the group. I guess we could add an attribute to expire a group, however no client will respect that for now, so it would be a bit pointless if not misguiding. Simo. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Granting rights temporarily
On Thu, 14 Feb 2013, Alexander Bokovoy wrote: On Thu, 14 Feb 2013, Dag Wieers wrote: So I was wondering whether this is something that was already discussed as a feature for IPA ? Yes, something along these lines was discussed in past. We have three tickets so far in deferred state: https: //fedorahosted.org/freeipa/ticket/547 https: //fedorahosted.org/freeipa/ticket/548 https: //fedorahosted.org/freeipa/ticket/3127 A problem with time-based access management is to consider its locality. Time-limited rules all stored centrally but applied locally and timezones play important role in messing things up. We also wanted to develop solution which would be scalable and easier to integrate with visual tools to edit recurrent events, thus ideas towards use of iCalendar (RFC5545 and RFC5546) format. From FreeIPA perspective application of rules would be done by SSSD and its plugins to various applications (sudo, SELinux enforcement, etc). FreeIPA itself would provide storage and means to edit the rules, both in command line and web UI. Thanks for the feedback. Obviously I didn't consider all the use-cases yet, but what you describe would fulfill the security recommendation. I'd like to start a feature proposal, however I am not sure if I am best placed to do it given there has obviously been discussions about it already (and our use-case is rather limited). Let me know if you see any value. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Granting rights temporarily
On Thu, 2013-02-14 at 08:30 -0700, Rich Megginson wrote: On 02/14/2013 06:54 AM, Simo Sorce wrote: On Thu, 2013-02-14 at 10:02 +0100, Dag Wieers wrote: Hi, Another interesting recommendation from security is that all granted access (that is exceptional, rather than permanent) should be limited in time from the onset. If this is not possible all granted access needs to be documented and revised regularly. However a system that would automatically revoke access after a certain period is preferred from a security/administrative perspective. (Period to be defined when granting access) This would mean that e.g. sudo-rules, group memberships, etc. could have due dates and that IPA ensures that these rights are revoked in due time. So I was wondering whether this is something that was already discussed as a feature for IPA ? sudo rules have sudoNotBefore sudoNotAfter attributes, so you can limit their validity. User accounts have an expiration time as well. There is no expiration time for groups or group membership, we have not had any previous request or need for this and I am not sure it really is possible to do this for group memberships. Someone was asking for this in one of the OpenLDAP forums. They want to be able to expire group membership after a certain time. They were going to create a new syntax which would be something like generalizedTime DELIM distinguishedName e.g. dn: cn=temporaryAdminGroup, timedmember: 2013021512Z$uid=richm,.. After 2013021512Z is hit, the value would be removed from the group. To me it looks like a bad hack and breaks all exiting clients. I do not think it is a viable interface except for purpose built software. 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] ipa-server-install IndexError: list index out of range
On Feb 12, 2013, at 6:57 PM, Rob Crittenden rcrit...@redhat.com wrote: Rob Crittenden wrote: Chuck Lever wrote: On Feb 12, 2013, at 4:24 PM, Rob Crittenden rcrit...@redhat.com wrote: Chuck Lever wrote: Hi- I'm new to FreeIPA. I'm installing on an up-to-date Fedora 18 system from the freeipa packages available with Fedora 18. When running ipa-server-install, the install process fails here: Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/20]: creating certificate server user ... [15/20]: requesting RA certificate from CA Unexpected error - see /var/log/ipaserver-install.log for details: IndexError: list index out of range The tail of the installer log looks like this: Generating key. This may take a few moments... 2013-02-12T21:04:46Z INFO File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 617, in run_script return_value = main_function() File /sbin/ipa-server-install, line 986, in main dm_password, subject_base=options.subject) File /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line 621, in configure_instance self.start_creation(runtime=210) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 358, in start_creation method() File /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line 1219, in __request_ra_certificate self.requestId = item_node[0].childNodes[0].data 2013-02-12T21:04:46Z INFO The ipa-server-install command failed, exception: IndexError: list index out of range Is there a workaround or fix available? I haven't found any relevant information via a web search, and a few searches on bugzilla.redhat.com have come up empty. We've seen just one other report of this and unfortunately the VM was removed before we could do a lot of diagnosis. What we saw was that certutil output garbage when requesting the RA admin certificate. Can you look in /var/log/ipaserver-install.log for the last certutil command? Does stdout contain a lot of garbage characters in it? It should consist of a base64-encoded CSR. 2013-02-12T21:04:29Z DEBUG [15/20]: requesting RA certificate from CA 2013-02-12T21:04:29Z DEBUG Starting external process 2013-02-12T21:04:29Z DEBUG args=/usr/bin/certutil -d /etc/httpd/alias -f -R -k rsa -g 2048 -s CN=IPA RA,O=1015GRANGER.NET -z /tmp/tmptIYFZ5 -a 2013-02-12T21:04:33Z DEBUG Process finished, return code=0 2013-02-12T21:04:33Z DEBUG stdout=^X^\FB^^@^@^@^X^\FB^^@^@^@^P-85^B^@^@^@^@^P- 85^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@@^G C18^?^@^@C1^E^@^@^@^@^@^@98^WFB^^@^@^@98^WFB^^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@F6F5D7F7Ƣ87C7CA^UCE^^F06ĸ^L^R|C0D6D3=^^W^D^N A1^\=9FFE^@^@^@^@^@^@^@^@q^E^@^@^@^@^@^@98^WFB^^@^@^@^PU+0084^B^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@B0^Y85^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@F0^AC2_^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@F0+C1_^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A ^@^@^@^@^@^@^@^@^@^@^@^@^@^@B0^@^@^@^@^@^@^@C1^D^@^@^@^@^@^@98^WFB^^@^@^@F0* 85^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@80BD84^B^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@P^@^@^@^@^@^@^@^P^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@! ^! @^@^@^@^@` ^B^@^@^@^@^@^@^P^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ 2013-02-12T21:04:33Z DEBUG stderr= If so, what version of nss and nss-tools do you have installed? [root@forain ~]# yum info nss
Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC
On 02/13/2013 04:10 PM, Rob Crittenden wrote: Also since we also require compatibility with Solaris, and roles (RBAC) is currently used on Solaris, does IPA support RBAC on Solaris ? (We noticed that RBAC mentioned in the IPA web interface only relates to IPA management). No, IPA doesn't support RBAC on Solaris. I've come across the same issue. This is just a matter of extending the schema. Would there be any interest for adding the Solaris RBAC schema as a part of the standard IPA distributed LDAP schemas? Regards, Siggi ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC
Sigbjorn Lie wrote: On 02/13/2013 04:10 PM, Rob Crittenden wrote: Also since we also require compatibility with Solaris, and roles (RBAC) is currently used on Solaris, does IPA support RBAC on Solaris ? (We noticed that RBAC mentioned in the IPA web interface only relates to IPA management). No, IPA doesn't support RBAC on Solaris. I've come across the same issue. This is just a matter of extending the schema. Would there be any interest for adding the Solaris RBAC schema as a part of the standard IPA distributed LDAP schemas? Is the schema enough? Won't people want a way from IPA to manage the data too? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC
On Thu, 2013-02-14 at 18:56 +0100, Sigbjorn Lie wrote: On 02/13/2013 04:10 PM, Rob Crittenden wrote: Also since we also require compatibility with Solaris, and roles (RBAC) is currently used on Solaris, does IPA support RBAC on Solaris ? (We noticed that RBAC mentioned in the IPA web interface only relates to IPA management). No, IPA doesn't support RBAC on Solaris. I've come across the same issue. This is just a matter of extending the schema. Would there be any interest for adding the Solaris RBAC schema as a part of the standard IPA distributed LDAP schemas? Regards, Siggi ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-usersSiggi, Yes, I had asked for this back in late 2011. I am glad to see that Dag Wieers is asking for it also. https://www.redhat.com/archives/freeipa-users/2011-November/msg00053.html Regards, Rodney. -- Rodney Mercer Systems Administrator ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC
On Thu, 14 Feb 2013, Rob Crittenden wrote: Sigbjorn Lie wrote: On 02/13/2013 04:10 PM, Rob Crittenden wrote: Also since we also require compatibility with Solaris, and roles (RBAC) is currently used on Solaris, does IPA support RBAC on Solaris ? (We noticed that RBAC mentioned in the IPA web interface only relates to IPA management). No, IPA doesn't support RBAC on Solaris. I've come across the same issue. This is just a matter of extending the schema. Would there be any interest for adding the Solaris RBAC schema as a part of the standard IPA distributed LDAP schemas? Is the schema enough? Won't people want a way from IPA to manage the data too? Of course, integration in IPA is better, but having the schema integrated is a good first step. Besides, integration in IPA probably won't happen without RBAC support in Fedora/RHEL, right ? -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC
Dag Wieers wrote: On Thu, 14 Feb 2013, Rob Crittenden wrote: Sigbjorn Lie wrote: On 02/13/2013 04:10 PM, Rob Crittenden wrote: Also since we also require compatibility with Solaris, and roles (RBAC) is currently used on Solaris, does IPA support RBAC on Solaris ? (We noticed that RBAC mentioned in the IPA web interface only relates toIPA management). No, IPA doesn't support RBAC on Solaris. I've come across the same issue. This is just a matter of extending the schema. Would there be any interest for adding the Solaris RBAC schema as a part of the standard IPA distributed LDAP schemas? Is the schema enough? Won't people want a way from IPA to manage the data too? Of course, integration in IPA is better, but having the schema integrated is a good first step. Besides, integration in IPA probably won't happen without RBAC support in Fedora/RHEL, right ? Right, and it is a bit beyond our scope to create a compatible RBAC solution. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
