Re: [Freeipa-users] RHEL6.3 documentation error...
Hi Steven, thanks for reporting this, I created a Bugzilla for the doc: https://bugzilla.redhat.com/show_bug.cgi?id=824768 Martin On Thu, 2012-05-24 at 04:26 +, Steven Jones wrote: Hi, Page 381 section 18.7.2 says, ipa replica-manage connect srv2.example.com srv4.example.com when n fact there needs to be a - in there, eg., vuwunicoipam001.ods.vuw.ac.nz: master [root@vuwunicoipam001 ~]# ipa replica-manage ipa: ERROR: unknown command 'replica-manage' [root@vuwunicoipam001 ~]# [root@vuwunicoipam001 ~]# ipa replica-manage help ipa: ERROR: unknown command 'replica-manage' [root@vuwunicoipam001 ~]# ipa-replica-manage help Usage: ipa-replica-manage [options] ipa-replica-manage: error: must provide a command [force-sync | disconnect | list | del | connect | re-initialize] [root@vuwunicoipam001 ~]# [root@vuwunicoipam001 ~]# ipa-replica-manage list Directory Manager password: vuwunicoipam001.ods.vuw.ac.nz: master [root@vuwunicoipam001 ~]# regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ___ 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] two way changes
On Thu, 2012-05-24 at 05:50 +, Steven Jones wrote: Hi, Just windering but I thought that whether I did change son the original master, or on the replica that changes would flow to the other both ways? or do changes only flow original master to replica? Since we use multi-master replication, the LDAP changes should flow both ways, i.e. when you change data either on master or replica - of course, if the attribute or the tree itself is replicated. If the replication is not working properly for you, I would check dirsrv error log, it may contain some relevant error messages. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa ports
On Wed, 2012-05-23 at 19:27 -0400, Dmitri Pal wrote: On 05/23/2012 05:40 PM, Jan-Frode Myklebust wrote: We have quite strict firewalls, so I need to specify the IPA network ports accurately. So, we have now opening for: 80/tcp, 88/tcp, 389/tcp, 443/tcp, 464/tcp, 636/tcp 88/udp, 464/udp in to our first IPA server. Now I'm in the process of configuring the first replica. Is there any other ports that needs to be opened between ipa master and replica? We don't serve NTP or DNS from IPA, so I guess these shouldn't be relevant, but I think we want dogtag replicated, so there's maybe some ports for that that needs opening ? Or, to put it another way, which of these ports: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Preparing_for_an_IPA_Installation.html#prereq-ports needs to be opened between ipa server, which for all clients, which for replica and which for administrative clients ? HTTP/HTTPS -- open for all LDAP/LDAPS -- open for all Kerberos-- open for all OCSP responder -- open for all if we use certs dogtag 9443 (agents)-- ? dogtag 9444 (users, SSL)-- ? dogtag 9445 (administrators)-- ? dogtag 9446 (users, client authentication) -- ? dogtag 9701 (Tomcat)-- ? dogtag 7389 (internal LDAP database) -- ? Dogtag ports are now proxied vial HTTP Exactly. So in your case, between replicas, you would need to open ports you specified: 80/tcp, 88/tcp, 389/tcp, 443/tcp, 464/tcp, 636/tcp 88/udp, 464/udp + the proxy port: 7389/tcp I suppose you don't need to open 7389/tcp for all clients unless you want them to be able to run LDAP search against dogtag backend LDAP database. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa ports
On Thu, May 24, 2012 at 10:50:23AM +0200, Martin Kosek wrote: I suppose you don't need to open 7389/tcp for all clients unless you want them to be able to run LDAP search against dogtag backend LDAP database. I don't see why I would want that, so I'll just open it between the ipa-servers for now. The ipa-replica-conncheck utility looks great, thanks! -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] freeIPA 2.2.0 on Fedora core 16?
Gelen James wrote: Hi all, Could FC16 installed FreeIPA 2.2.0? the freeIPA site said that FC16 has some underlying dependencies. It is possible to build it and install in F-16 but you'll have SELinux problems. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Custom ACI entries
On 05/17/2012 10:47 AM, Lucas Yamanishi wrote: On 05/17/2012 09:34 AM, Rob Crittenden wrote: Lucas Yamanishi wrote: Hi everybody, I've added some custom schema to my directory, but it's useless to me if if I can't control read permissions on it. This is obviously a little tricky since (Free)IPA allows everybody to ready everything by default. With that, what's the best way to restrict access to user attributes? Is there anything like this in the roadmap? Right now there is are no plans to support deny ACIs natively in the permission plugin. That isn't set into stone, we just need some convincing. Then let me make the case: I know IPA is aimed mainly at authentication and authorization, but it provides enough base schema and tree structure to do basic asset and personnel management. More importantly, it's easier to setup than a pure 389 Directory. This makes it ideal for small to medium sized organizations that don't need the extra utility a separate directory provides. Additionaly, the well-designed webui makes it easy to delegate tasks to non-technical personnel. The requirements to achieve this end are two: add native support for a restricted set of schema extensions and fine-grained access controls to those attributes. For schema extensions, support could (and should) be limited only to additional attributes on a restricted set of existing objects. For example, additions to users and hosts. This would satisfy requirements for a majority of small to medium sized organizations, I'd think. Building a generic mechanism is really a lot of work. It might be simpler to do it differently, i.e. incrementally add support for additional attributes. Do you have the schema that you added handy? What is the application that uses it? Is it popular? Is it open source? If it is it might make sense to just support these attributes our of box if the schema is loaded. The best way to do this is what you've done, manually creating ACIs. The problem with deny ACIs is they can get very hard to unwind when trying to figure out why things aren't working. How do you mean? For the interim I've crafted some custom aci entries. Where should I put them? Will they work? Here they are: aci: (targetattr = attribute1 || attribute2 || attribute3) (version 3.0; acl custom attributes base; deny (all) (userdn = ldap:///anyone; and userdn != ldap:///self; and groupdn != ldap:///cn=Read custom attributes,cn=permissions,cn=pbac,dc=sesda2,dc=com);) aci: (targetattr = attribute1 || attribute2 || attribute3) (version 3.0; acl custom attributes update; allow (add, read, write, search, delete) (userdn = ldap:///self; or groupdn = ldap:///cn=Manage custom attributes,cn=permissions,cn=pbac,dc=sesda2,dc=com);) We put all ACIs into the basedn, so for you dc=sesda2,dc=com. This is going to be tricky since you want to delegate these but you can't create them natively. This means you need to create both the aci and the permission entry. A sample permission would look like: dn: cn=Read custom attributes,cn=permissions,cn=pbac,dc=sesda2,dc=com objectClass: top objectClass: groupofnames objectClass: ipapermission cn: Read custom attributes Can't I add these via ipa permission-add or the webui? The ACIs need a little bit of work. The name of the aci needs to match the name of the ACI that permission is being granted to, with a prefix of permission:. So it should look more like: aci: (targetattr = attribute1 || attribute2 || attribute3) (version 3.0; acl permission:Read custom attributes; deny (all) (userdn = ldap:///anyone; and userdn != ldap:///self; and groupdn != ldap:///cn=Read custom attributes,cn=permissions,cn=pbac,dc=sesda2,dc=com);) For the second ACI you don't need add and delete, those are entry-level permissions. You might want to add compare though. We also tend to separate things you can do to your own entry from things you can do to others. So we would break this out into some selfservice ACIs and permission ACIs. Not saying what you're doing won't work. rob Thanks! -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Please help: What the purposes of '--usercat' and '--hostcat' options to IPA net groups?
On 05/16/2012 06:20 AM, Sumit Bose wrote: On Tue, May 15, 2012 at 09:05:43AM -0700, Gelen James wrote: Hi Sumit, Thanks for your quick reply. In the chapter http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6-Beta/html/Identity_Management_Guide/migrating-from-nis.html#nis-import-netgroups, The Netgroup migration script sets '--usercat' and '--hostcat' options to IPA netgroups through 'ipa netgroup-mod' command. More specifically, when IPA imports host based netgroups with triples like (hostA,-,-), (hostB,-,-), The new IPA netgroups are set up with option '--usetcat=all'. Does that means if this IPA netgroup is used in a HBAC rule, then the rule will applied to all users on hostA and hostB. am I right? :) yes, this is my understanding, too. BTW, do I have to turn on the '--usercat' option for NIS netgroup migration? The HBAC rules are defined inside hosts/hostgroups, and no NIS groups are involved, right? I maybe completely wrong here. yes, HBAC rules use hosts/hostgroups and not netgroups. In general netgroups were added to support application which still needs them or to make migrations from environments where netgroups were used easier. But we recommend to use hostgroups with IPA if possible. HTH bye, Sumit Thanks. --Gelen From: Sumit Bose sb...@redhat.com To: freeipa-users@redhat.com Sent: Tuesday, May 15, 2012 1:48 AM Subject: Re: [Freeipa-users] Please help: What the purposes of '--usercat' and '--hostcat' options to IPA net groups? On Mon, May 14, 2012 at 07:57:06PM -0700, David Copperfield wrote: Hi all, The online manual says that the '--usercat' means 'User category the rule applies to'; '--hostcat' has the similar explanation. But I still don't understand how that could be used in real life and when/where to use the options. Could anyone please shed a light on this? Thanks a lot. iirc these options where introduced with the host based access control (HBAC) and are used to identify categories/classes of users and hosts in a more general way than using groups or ip-address ranges. I think currently only the keyword 'all' can be used here, which e.g means that an HBAC rule will match for all users or all hosts. In future it is planned to support other categories, e.g. something like 'local' and 'remote' which would catch all users/hosts of the local IPA domain or all users/groups which are coming from remote domains ,respectively. HTH bye, Sumit Finally got time to read and reply. The IPA introduced and object class called Association. It allows many-to-many relationship between users and hosts. Uses can be expressed as list of users, list of groups, or category of users. We currently support only one category all. Same is with hosts. Several different objects in IPA derive from the association object. HBAC and netgroups are among those. This is why the notion of the category is in both cases. But it also makes sense. There was no other way for HBAC and netgroups to express all. We made an architectural decision that absence of something should not be treated as all but rather denote none. So if nothing is defined in the HBAC rule to express users such rule should be treated as not applying to any user and effectively be ignored as incomplete/broken rule. If it is not the case it is probably a bug. --David ___ 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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
