Re: [Freeipa-users] Solaris 10 as IPA Client?
Hi, I use Solaris 10 as clients, several different updates. They all work fine. I have replaced the default DUAConfigProfile though, to include netgroups and automount support, and use SSL authenticated connctions, but the default should work well for basic user and group. Even though it uses unencrypted, unauthenticated connections to the LDAP server. :) Please note that you really need to change /etc/nsswitch.ldap before running the ldapclient script, as this is being copied into /etc/nsswitch.conf by the ldapclient script. The default nsswitch.ldap sets hosts to look from ldap, and removes dns. This does not work with IPA as it relies on DNS for name lookups, and the hosts tables does not exist in IPA's LDAP server. This prevents the ldap client from starting. I've configured my nsswitch.ldap to only look up passwd, group, automount, netgroup and ethers for now. Remember to configure the kerberos client afterwards. AES256 (which is the first KRB encryption type in IPA) was not included in Solaris 10 until Update 8 from what I've read. On these machines I have created keytabs using only AES128 and below for the keytab, and limiting enctypes in krb5.conf using default_tkt_enctypes and default_tgs_enctypes to AES128 and downwards. Regards, Siggi On Thu, December 1, 2011 06:31, Craig T wrote: Hi, Anyone had any success using Solaris 10 as a IPA client (using ipa-server-2.1.1-4.el6.x86_64)? Does anyone have any more detailed documentation on the topic? I find that Section 3.3.1. Configuring Solaris 10 from the Identitiy Management Guide very light. #Solaris 10 (Newest Edition) Oracle Solaris 10 8/11 s10x_u10wos_17b X86 Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved. Assembled 23 August 2011 bash-3.2# ldapclient -v init chtvm-389.teratext.saic.com.au Arguments parsed: defaultServerList: chtvm-389.teratext.saic.com.au Handling init option About to configure machine by downloading a profile No profile specified. Using default Proxy DN: NULL Proxy password: NULL Authentication method: 0 No proxyDN/proxyPassword required Shadow Update is not enabled, no adminDN/adminPassword is required. About to modify this machines configuration by writing the files Stopping network services Stopping sendmail stop: sleep 10 microseconds stop: network/smtp:sendmail... success Stopping nscd stop: sleep 10 microseconds stop: sleep 20 microseconds stop: system/name-service-cache:default... success Stopping autofs stop: sleep 10 microseconds stop: sleep 20 microseconds stop: sleep 40 microseconds stop: sleep 80 microseconds stop: sleep 160 microseconds stop: sleep 320 microseconds stop: system/filesystem/autofs:default... success ldap not running nisd not running nis(yp) not running file_backup: stat(/etc/nsswitch.conf)=0 file_backup: (/etc/nsswitch.conf - /var/ldap/restore/nsswitch.conf) file_backup: stat(/etc/defaultdomain)=0 file_backup: (/etc/defaultdomain - /var/ldap/restore/defaultdomain) file_backup: stat(/var/nis/NIS_COLD_START)=-1 file_backup: No /var/nis/NIS_COLD_START file. file_backup: nis domain is teratext.saic.com.au file_backup: stat(/var/yp/binding/teratext.saic.com.au)=-1 file_backup: No /var/yp/binding/teratext.saic.com.au directory. file_backup: stat(/var/ldap/ldap_client_file)=-1 file_backup: No /var/ldap/ldap_client_file file. Starting network services start: /usr/bin/domainname teratext.saic.com.au... success start: sleep 10 microseconds start: sleep 20 microseconds start: sleep 40 microseconds start: sleep 80 microseconds start: sleep 160 microseconds start: sleep 320 microseconds start: sleep 640 microseconds start: sleep 1280 microseconds start: sleep 2560 microseconds start: sleep 5120 microseconds start: sleep 1770 microseconds start: network/ldap/client:default... timed out start: network/ldap/client:default... offline to disable stop: sleep 10 microseconds stop: sleep 20 microseconds stop: sleep 40 microseconds stop: sleep 80 microseconds stop: sleep 160 microseconds stop: sleep 320 microseconds stop: sleep 640 microseconds stop: sleep 1280 microseconds stop: sleep 2560 microseconds stop: sleep 890 microseconds stop: network/ldap/client:default... timed out start: sleep 10 microseconds start: system/filesystem/autofs:default... success start: sleep 10 microseconds start: system/name-service-cache:default... success start: sleep 10 microseconds start: sleep 20 microseconds start: network/smtp:sendmail... success restart: sleep 10 microseconds restart: milestone/name-services:default... success Error resetting system. Recovering old system settings.
Re: [Freeipa-users] Limiting group/user visibility
On Wed, Nov 30, 2011 at 01:18:46PM +0200, Lassi Pölönen wrote: Hi, I'm looking for implementing FreeIPA in an environment where there are multiple customers in multiple organizations and a single organization that manages the users, sets the access rights etc. We don't have a centralized system currently so I will be starting from the scratch in that sense. The first concern I've had so far is that we don't want different customers to be able to find information about each other. Currently in my test setup any user can find out every user in a group if they know the group name and all the groups for each user if they know the username. In some cases this might reveal information the customer is not willing to share. So are there ways to limit that e.g certain hosts/hostgroups or users/usergroups see some defined subset of the directory? Or are there some other suggested approaches? As the current setup relies on local authentication, users naturally are able to find users/groups only on servers they are able to log in and that is the level of confidentiality we are looking for if possible -Lassi Pölönen If you insist on a single instance for multiple organizations, then I agree with Stephen Ingram that the correct way would be to setup ACIs. You could also abuse the ldap_user_search_filter and ldap_group_search_filter parameters to limit NSS lookups performed by SSSD. However, nothing would prevent clients from looking at the directory structure with ldapsearch or using the IPA UI. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Limiting group/user visibility
On Thu, 2011-12-01 at 13:46 +0100, Jakub Hrozek wrote: On Wed, Nov 30, 2011 at 01:18:46PM +0200, Lassi Pölönen wrote: Hi, I'm looking for implementing FreeIPA in an environment where there are multiple customers in multiple organizations and a single organization that manages the users, sets the access rights etc. We don't have a centralized system currently so I will be starting from the scratch in that sense. The first concern I've had so far is that we don't want different customers to be able to find information about each other. Currently in my test setup any user can find out every user in a group if they know the group name and all the groups for each user if they know the username. In some cases this might reveal information the customer is not willing to share. So are there ways to limit that e.g certain hosts/hostgroups or users/usergroups see some defined subset of the directory? Or are there some other suggested approaches? As the current setup relies on local authentication, users naturally are able to find users/groups only on servers they are able to log in and that is the level of confidentiality we are looking for if possible -Lassi Pölönen If you insist on a single instance for multiple organizations, then I agree with Stephen Ingram that the correct way would be to setup ACIs. You could also abuse the ldap_user_search_filter and ldap_group_search_filter parameters to limit NSS lookups performed by SSSD. However, nothing would prevent clients from looking at the directory structure with ldapsearch or using the IPA UI. Please note that the *search_filter options aren't fully functional yet. We're improving them substantially for the 1.7.0 release of SSSD. But Jakub is right: if you manipulate the ACIs of your user entries, then you can restrict which client machines can see those entries. signature.asc Description: This is a digitally signed message part ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Using the freeipa 389 ds installation for own stuff
On Fri, 2011-12-02 at 02:07 +0100, Johannes von Bargen wrote: Hi! The documentation strongly emphasises that the difference between freeipa and the pre 389 directory server (https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/introduction.html#comparing). Does it lead to problems if I use the directiory server which is the backend for freeipa for other stuff, like postfix/dovecot users? No it shouldn't as long as user/group creation is done through IPa you shouldn't have issues. You may need to write some customization if you need to add mandatory attributes at user object creation but this has been previously documented in this list. We also have documents on how to extend the FreeIPA framework with new modules in case you wish to create native management interfaces in FreeIPA to manage the objects you need. In order to better future-proof I also suggest you place custom objects in a clearly named subtree (like cn=yourorgname) under the base suffix so that you do not risk conflicts when we add new features in IPA in the future. 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] Limiting group/user visibility
On 2011-12-01 19:01, Lassi Pölönen wrote: On 1.12.2011 15:12, Stephen Gallagher wrote: On Thu, 2011-12-01 at 13:46 +0100, Jakub Hrozek wrote: On Wed, Nov 30, 2011 at 01:18:46PM +0200, Lassi Pölönen wrote: Hi, I'm looking for implementing FreeIPA in an environment where there are multiple customers in multiple organizations and a single organization that manages the users, sets the access rights etc. We don't have a centralized system currently so I will be starting from the scratch in that sense. The first concern I've had so far is that we don't want different customers to be able to find information about each other. Currently in my test setup any user can find out every user in a group if they know the group name and all the groups for each user if they know the username. In some cases this might reveal information the customer is not willing to share. So are there ways to limit that e.g certain hosts/hostgroups or users/usergroups see some defined subset of the directory? Or are there some other suggested approaches? As the current setup relies on local authentication, users naturally are able to find users/groups only on servers they are able to log in and that is the level of confidentiality we are looking for if possible -Lassi Pölönen If you insist on a single instance for multiple organizations, then I agree with Stephen Ingram that the correct way would be to setup ACIs. You could also abuse the ldap_user_search_filter and ldap_group_search_filter parameters to limit NSS lookups performed by SSSD. However, nothing would prevent clients from looking at the directory structure with ldapsearch or using the IPA UI. Please note that the *search_filter options aren't fully functional yet. We're improving them substantially for the 1.7.0 release of SSSD. But Jakub is right: if you manipulate the ACIs of your user entries, then you can restrict which client machines can see those entries. Ok, thanks for the replies. ACIs sound like pretty much the only feasible solution and still less things to maintain than completely dedicated setups. Will look in to 389's documentation for more. Replying to myself.. Actually I would think my goal would be pretty typical setup for managed hosting companies like us as we are the ones who manage all the accounts and servers for our customer organizations. We grant customer access to servers we host and we should have our own accounts on every server as well. Running multiple domains in this case means we would need to replicate our admin accounts to every domain (not sure if there's even a feasible solution to do that) and also manage customer accounts on multiple FreeIPA installations. Running a single domain would make it easier to provide a single account for customers for services that are common to every customer, e.g ticketing system, wikis and so on. It's just that they shouldn't be able to know about each other. Anyway, looking at macro ACIs, it at least looks like it's possible to accomplish with a few pretty simple rules. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
