Re: [Freeipa-users] check host password age
On 12.3.2013 14:41, Stijn De Weirdt wrote: hi all, (i'm new to freeipa, so it's possible i missed some docs here and there ;) i'm looking to add hosts with some secret password to ipa, then during kickstart install they use this password to run ipa-client-install. You need to add host account beforehand: $ ipa host-add hostname.example.com --password=secret # or --random Computer accounts created this way do not have Kerberos attributes present in LDAP: $ ldapsearch -Y GSSAPI -b 'fqdn=hostname.example.com,cn=computers,cn=accounts,dc=example,dc=com' '(objectclass=*)' krbLastPwdChange krbLastSuccessfulAuth modifyTimestamp # hostname.example.com, computers, accounts, r.test dn: fqdn=hostname.example.com,cn=computers,cn=accounts,dc=example,dc=com modifyTimestamp: 20130313083220Z Kerberos attributes should be created during host enrolment process, so you can query krbLastPwdChange attribute: $ ldapsearch -Y GSSAPI -b 'fqdn=hostname.example.com,cn=computers,cn=accounts,dc=example,dc=com' '(objectclass=*)' krbLastPwdChange krbLastSuccessfulAuth modifyTimestamp krbLastPwdChange: 20130313084141Z krbLastSuccessfulAuth: 20130313084143Z modifyTimestamp: 20130313084146Z what i would like to do, is to check for all hosts which have a password that is older then a certain age. for those i will assume that something has gone wrong and i would like to close the installation window. (and i would do so by assigning another random password to that host) I would recommend $ ipa host-disable hostname.example.com i guess the timestamps are somehwere in the ldap schema, i would like to know where or how i can find them. and if possible, how to do that using the ipalib python api. btw, is it correct for me to assume that when has_keytab=True that the host password is useless or even better unusable with that host? Sorry, I have to defer this question to more competent people :-) i'm running 3.0.0-25 on a sl6 machine. -- Petr^2 Spacek ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] check host password age
On 03/13/2013 09:55 AM, Petr Spacek wrote: On 12.3.2013 14:41, Stijn De Weirdt wrote: ... i guess the timestamps are somehwere in the ldap schema, i would like to know where or how i can find them. and if possible, how to do that using the ipalib python api. btw, is it correct for me to assume that when has_keytab=True that the host password is useless or even better unusable with that host? Sorry, I have to defer this question to more competent people :-) I think you could rather check that has_password=False. This effectively means that the principal has no userPassword attribute which could be used for authentication. has_keytab=True means that keys/keytab was generated, i.e. krbPrincipalKey is present. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] check host password age
i'll get back to the previous part later, wehn i can test it (thanks petr!) i guess the timestamps are somehwere in the ldap schema, i would like to know where or how i can find them. and if possible, how to do that using the ipalib python api. btw, is it correct for me to assume that when has_keytab=True that the host password is useless or even better unusable with that host? Sorry, I have to defer this question to more competent people :-) I think you could rather check that has_password=False. This effectively means that the principal has no userPassword attribute which could be used for authentication. has_keytab=True means that keys/keytab was generated, i.e. krbPrincipalKey is present. the flow as i see it is the following: a .new host, with random password : has_password=True, has_keytab=False b after succesful ipa-client-install : has_keytab=True, has_password=? c. no succesful ipa-client-install: has_password=True, has_keytab=False suppose i want to check which hosts have an old password, is should just check all nodes with has_password=True and fetch the date through ldap. but if in case b the password is still set (has_password=True), how can i disable password access? or should i not worry about passwords when has_keytab=True? stijn ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Postfix and FreeIPA in a secure setup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/12/2013 02:05 PM, Anthony Messina wrote: On Tuesday, March 12, 2013 08:53:59 AM Anthony Messina wrote: On Tuesday, March 12, 2013 01:50:47 PM Dale Macartney wrote: # Import environment for Kerberos v5 GSSAPI import_environment = MAIL_CONFIG MAIL_DEBUG MAIL_LOGTAG TZ XAUTHORITY DISPLAY LANG=C KRB5_KTNAME=/etc/postfix/smtp.keytab Anthony, where were you declaring the above? In Squid, I've added the keytab to the service startup script. Presumably it would be somewhere similar? Dale In /etc/postfix/main.cf Sorry, I sent too fast. from man (5) postconf: import_environment (default: see postconf -d output) The list of environment parameters that a Postfix process will import from a non-Postfix parent process. Examples of relevant parameters: TZ Needed for sane time keeping on most System-V-ish systems. DISPLAY Needed for debugging Postfix daemons with an X-windows debugger. XAUTHORITY Needed for debugging Postfix daemons with an X-windows debugger. MAIL_CONFIG Needed to make postfix -c work. Specify a list of names and/or name=value pairs, separated by whitespace or comma. The name=value form is supported with Postfix version 2.1 and later. Things aren't really playing ball here I've configured postfix from default install with the below changes.. Am I missing something? ipa-getkeytab -s ds01.example.com -p smtp/$(hostname) -k /etc/postfix/smtp.keytab postconf -e 'inet_interfaces = all' postconf -e 'mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain' postconf -e 'myorigin = $mydomain' postconf -e 'import_environment = MAIL_CONFIG MAIL_DEBUG MAIL_LOGTAG TZ XAUTHORITY DISPLAY LANG=C KRB5_KTNAME=/etc/postfix/smtp.keytab' postconf -e 'smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination' postconf -e 'smtpd_sasl_auth_enable = yes' postconf -e 'smtpd_sasl_security_options = noanonymous' postconf -e 'smtpd_sasl_tls_security_options = $smtpd_sasl_security_options' cat /etc/postfix/main.cf EOF virtual_alias_domains = example.com virtual_alias_maps = ldap:/etc/postfix/ldap_aliases.cf EOF cat /etc/postfix/ldap_aliases.cf EOF server_host = ds01.example.com search_base = cn=accounts,dc=example,dc=com query_filter = (mail=%s) result_attribute = uid bind = no start_tls = yes version = 3 EOF postmap /etc/postfix/ldap_aliases.cf restorecon -R /etc/postfix/ cat /etc/sasl2/smtpd.conf EOF pwcheck_method: saslauthd mech_list: GSSAPI PLAIN LOGIN EOF LDAP lookups work perfectly, however kerberos authentication doesn't seem to want to work. I should mention, I am not using SSL (yet). Does sasl/gssapi have some form of prereq of SSL by any chance? Logs from maillog are as follows Mar 12 15:51:27 mail01 postfix/smtpd[26240]: connect from unknown[10.0.1.101] Mar 12 15:51:27 mail01 postfix/smtpd[26240]: warning: SASL authentication failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information () Mar 12 15:51:27 mail01 postfix/smtpd[26240]: warning: unknown[10.0.1.101]: SASL GSSAPI authentication failed: generic failure Mar 12 15:51:27 mail01 postfix/smtpd[26240]: disconnect from unknown[10.0.1.101] Thanks all ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRQFlOAAoJEAJsWS61tB+qHFcP+gJWHxYHh+VdnpEGBg0gFMdm iHEe568jU7gDe5UdUP52RzUKIRYdSH3QRoYi4X8VIVjSIo8wlSWHEspvJlgjLDXE zsV9hGzINF/XNBnX9kA/h94fzvWjgHq5DsTXrCiymtjAyDSQJVWR10j4zCEN6Nwp rA68xlWpnqRE54zlSJx1QTF+pHp7KIvTbJ2QZQuOVBpXKK4HuKkt4XSrSgHvNAaZ lqxINgbfrApde8wuaGcz7JgfcMGeOiDA08oUSyZCch8gyLC1DdMvbtaElECce6ea dhbzchbz8sVtUFyXcsNk3M9x6dLWUFPuQ5IzPfwGv8UjXAaXeYKIXpwlNkAyb0lC x7COqcGRMArl6e+YY6VyMHgwHgAEcn69WfVbkGZAgGAkMs3gEce2a7JtmiYm/Os5 Ax757W4dJjxkJg3iu11kAfO90dhwYL3O9JB8yYPHuZYQpSogbp6aQUhiWXgydp1d 7rgZfitJehEPLKqwbOzYi7nBy9N+2zbP6pdom1oApHpXkC6iSro31wzQ5qCy1+Z2 m2CDExrFXEEu0UPIQvCd7BW43L2CYac91g89gwK3tLfT0tyX6zb6vKeFZ2tdrI8D FogyxaKLDE5gFhdk+O2SZghLniN0YefF/wKWAa++tC8o1U3SQKAP5aH15p9Le8Rt +NefKeJRsREs0Fx5XXQN =nOEI -END PGP SIGNATURE- ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA 3.0 transitive trust, multiple domains
On Tue, 12 Mar 2013, de Jong, Mark-Jan wrote:
Hello,
I'm currently testing forest trusts in v3.0 on CentOS 6.4. I've got a
trust setup between my IPA forest (nix.ipatest.dom) and my Windows
forest (ipatest.dom). I have gone though the setup procedure as outlined
at http://freeipa.org/page/Howto/IPAv3_AD_trust_setup.
Everything works as described in that document. However, now I want to
add groups to IPA from another domain in the windows forest
(us.ipatest.dom) but can't figure out how to proceed. When trying to add
the a group from the US domain I get the following:
[root@ipa01 ~]# ipa group-add-member ad_admins_external --external 'US
\Domain Admins'
[member user]:
[member group]:
ipa: ERROR: invalid Gettext('external member', domain='ipa',
localedir=None): values are not recognized as valid SIDs from trusted
domain
I understand the error, but am not sure how to get this to work.
Creating a new trust between the IPA forest and the US domain results in
the following error, presumably because it's a transitive trust:
[root@ipa01 ~]# ipa trust-add --type=ad us.ipatest.dom --admin
Administrator --password
Active directory domain administrator's password:
ipa: ERROR: invalid Gettext('AD domain controller', domain='ipa',
localedir=None): unsupported functional level
Any help would be greatly appreciated!
We don't support transitive trusts right now. There is work is being
done to implement them, tracked with
https://fedorahosted.org/freeipa/ticket/3510, though before we get there
we need to finish a foundational work, including some changes in Samba
I'm currently working on and changes for SSSD.
You can see progress with the ticket above and others mentioned in it.
--
/ Alexander Bokovoy
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Realm distrubuted across data centers
On Wed, 2013-03-13 at 09:28 -0400, Rob Crittenden wrote: Michael ORourke wrote: I think SRV records are only part of the problem. We are using integrated BIND/DNS with our IPA servers and I'm not sure it supports views. But thanks for the suggestion. I guess we could create custom krb5.conf files in each DC and mange them with Puppet, but there are other config files (e.g. resolv.conf and ldap.conf) that would need to be managed too. Maybe there are some other IPA client config files that setup static mappings during the join process. Anyone know which ones to look at? No, we don't support views yet. You'd also need a custom sssd.conf as well. We support this kind of configuration in 3.x. Using multiple --server and --fixed-primary options of ipa-client-install you can add multiple, hardcoded servers and still have failover. Basically you configure things to ignore the SRV records, so you shouldn't have to mess with the resolver at all. Just want to note that we are working on a more manageable solution for the future: http://www.freeipa.org/page/V3/DNS_Location_Mechanism But we are not there yet. 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] Realm distrubuted across data centers
On 13.3.2013 14:28, Rob Crittenden wrote: Michael ORourke wrote: I think SRV records are only part of the problem. We are using integrated BIND/DNS with our IPA servers and I'm not sure it supports views. But thanks for the suggestion. I guess we could create custom krb5.conf files in each DC and mange them with Puppet, but there are other config files (e.g. resolv.conf and ldap.conf) that would need to be managed too. Maybe there are some other IPA client config files that setup static mappings during the join process. Anyone know which ones to look at? No, we don't support views yet. Views are not supported in IPA admin tools, but generally views can be configured with some hacking around. The price for that is losing IPA admin tools for DNS and generally, it is ugly and hard to maintain. I wouldn't recommend that. Our latest greatest proposal for location auto-discovery in summarized at http://www.freeipa.org/page/V3/DNS_Location_Mechanism . Any comments are welcome! In your case with only 2 locations and 2 IPA servers in each location, it is relatively simple to prepare two sets of hand-crafted DNS records site1._locations.ipa.example.com and site2._locations.ipa.example.com and configure clients on each site to use these two domains (site1 and site2) according to their real network location. Disadvantages of hand-made records: - It can't handle mobile clients (i.e. travelling between 'sites'). - 'Domain' configured in SSSD has to be reconfigured on each client. Let me know if you want to go this way. (It should work with any IPA/DNS server.) Petr^2 Spacek You'd also need a custom sssd.conf as well. We support this kind of configuration in 3.x. Using multiple --server and --fixed-primary options of ipa-client-install you can add multiple, hardcoded servers and still have failover. Basically you configure things to ignore the SRV records, so you shouldn't have to mess with the resolver at all. rob - Original Message - *From:* Peter Brown mailto:rendhal...@gmail.com *To:* Michael ORourke mailto:mrorou...@earthlink.net *Cc:* freeipa-users mailto:freeipa-users@redhat.com *Sent:* Wednesday, March 13, 2013 12:58 AM *Subject:* Re: [Freeipa-users] Realm distrubuted across data centers I have no idea if this counts as best practice because I am not affiliated with the FreeIPA development team I personally think SRV records are probably the best idea in this situation. You would have to setup different zones to serve to each datacentre though if you know how to do that. It's not that tricky with views in bind. On 13 March 2013 12:40, Michael ORourke mrorou...@earthlink.net mailto:mrorou...@earthlink.net wrote: We have a single realm distributed across 2 data centers and 2 offices with 4 replicated IPA servers (2 in each data center). We are running IPA server and client v2.2.0 on all servers and replication appears to be functioning correctly. What I have noticed is that some servers in DC1, have no connectivity to the IPA servers in DC2, and when you try connecting to them from Office1 you sometimes get a long authentication delay. I suspect this is caused by a timeout waiting for an IPA server in DC2 to respond (which it can't). So I guess my question is, is there a 'best practices' approach to this scenario? -- Petr^2 Spacek ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Revisiting auditing and avoiding reinvention of round rolling things
Hi all. I know that the A part of IPA has been delayed, but that doesn't mean that the auditing requirement has gone away. Before I write a bunch of stuff for this, I wanted to see if anyone had any thoughts (or code!) regarding how to accomplish some of this stuff that auditors want to see. Here's an email I received from an EY auditor: ---cut--- Thanks for the great response! I think at this point its probably best to jump on a call/meet in person and try to figure out where to go from here. What we would like to understand is if IPA will be in scope for our audit this year. From what you have told me below, its 'possible' that user accounts on IPA may have access to our in-scope servers. And if this is the case we would need to obtain evidence of who has access to our in-scope servers through IPA, their level of access and how they authenticate to the server. Here's a couple of thoughts on my mind that I would like to discuss further before we 'formally' request this evidence: • Would we be able to obtain a 'system generated' list or screenshots showing all accounts on IPA that are able to access our in-scope servers? • Additionally, you mentioned that regular user accounts su or sudo to the application account (root). Would we be able to evidence which accounts on IPA are configured to able to su to the application account? • We would like to find a way to evidence the authentication path and the specific password parameters in place for the user accounts on IPA that we determine are in-scope for us this year. • How are accounts setup on IPA? What is the process for setting up new users? • Who has privileged access (the ability to add, delete or modify user accounts) to IPA and would we be able to obtain evidence to show who has these access rights. ---cut--- I know I can dump a list of users, then run that list through a series of HBAC tests to see if a user is allowed access to a particular server, but is there a say to easily ask what users can log into this server? Or even what users are allowed to su to this account on this server? as is being asked above? Does anyone already have any code they'd be willing to share to this end? Thanks for any thoughts at all, --Jason -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] add ldap group to local group
On Wed, 2013-03-13 at 16:12 +0100, Natxo Asenjo wrote: hi, is it possible to do that? If by local group you mean /etc/group then it is not possible. Posix does not understand nested groups. 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] Realm distrubuted across data centers
El mié, 13-03-2013 a las 14:44 +0100, Petr Spacek escribió: On 13.3.2013 14:28, Rob Crittenden wrote: Michael ORourke wrote: I think SRV records are only part of the problem. We are using integrated BIND/DNS with our IPA servers and I'm not sure it supports views. But thanks for the suggestion. I guess we could create custom krb5.conf files in each DC and mange them with Puppet, but there are other config files (e.g. resolv.conf and ldap.conf) that would need to be managed too. Maybe there are some other IPA client config files that setup static mappings during the join process. Anyone know which ones to look at? No, we don't support views yet. Views are not supported in IPA admin tools, but generally views can be configured with some hacking around. The price for that is losing IPA admin tools for DNS and generally, it is ugly and hard to maintain. I wouldn't recommend that. Our latest greatest proposal for location auto-discovery in summarized at http://www.freeipa.org/page/V3/DNS_Location_Mechanism . Any comments are welcome! Hi! The proposal seems to me too complicated, I really liked the old proposal where you could query the DNS which was the most appropriate site for your IP address. Choosing the right site by IP address is not perfect, there will be always some corner cases, but it is good enough and way better than what we have now. The problem could be addressed in two parts: 1) Add the concepts of sites to the IPA realm, and associate every server with one (and just one?) site, the generate the appropriate SRV record for every site. I did this manually, creating the SRV records one by one: _kerberos._udp.site1._sites.mydomain.com. IN SRV 0 100 88 ipa1.mydomain.com. ... When joining the host to the domain the admin may add the option --domain=site1._sites.mydomain.com to ipa-client-install to use the right ipa servers for that site. This first step could be added to IPA fairly easy and it would be a great improvement. 2) Add some kind of configurable locator policy to SSSD. There could be: 2.1) fixed site policy, which would use always the same site 2.2) CLDAP ping AD-like policy 2.3) a policy which reads and remember the right site per client or per ip address from LDAP on first connection... Just my $0.02! In your case with only 2 locations and 2 IPA servers in each location, it is relatively simple to prepare two sets of hand-crafted DNS records site1._locations.ipa.example.com and site2._locations.ipa.example.com and configure clients on each site to use these two domains (site1 and site2) according to their real network location. Disadvantages of hand-made records: - It can't handle mobile clients (i.e. travelling between 'sites'). - 'Domain' configured in SSSD has to be reconfigured on each client. Let me know if you want to go this way. (It should work with any IPA/DNS server.) Petr^2 Spacek You'd also need a custom sssd.conf as well. We support this kind of configuration in 3.x. Using multiple --server and --fixed-primary options of ipa-client-install you can add multiple, hardcoded servers and still have failover. Basically you configure things to ignore the SRV records, so you shouldn't have to mess with the resolver at all. rob - Original Message - *From:* Peter Brown mailto:rendhal...@gmail.com *To:* Michael ORourke mailto:mrorou...@earthlink.net *Cc:* freeipa-users mailto:freeipa-users@redhat.com *Sent:* Wednesday, March 13, 2013 12:58 AM *Subject:* Re: [Freeipa-users] Realm distrubuted across data centers I have no idea if this counts as best practice because I am not affiliated with the FreeIPA development team I personally think SRV records are probably the best idea in this situation. You would have to setup different zones to serve to each datacentre though if you know how to do that. It's not that tricky with views in bind. On 13 March 2013 12:40, Michael ORourke mrorou...@earthlink.net mailto:mrorou...@earthlink.net wrote: We have a single realm distributed across 2 data centers and 2 offices with 4 replicated IPA servers (2 in each data center). We are running IPA server and client v2.2.0 on all servers and replication appears to be functioning correctly. What I have noticed is that some servers in DC1, have no connectivity to the IPA servers in DC2, and when you try connecting to them from Office1 you sometimes get a long authentication delay. I suspect this is caused by a timeout waiting for an IPA server in DC2 to respond (which it can't). So I guess my question is, is there a 'best practices' approach to this scenario? -- Loris Santamaria linux user #70506 xmpp:lo...@lgs.com.ve Links Global Services, C.A.http://www.lgs.com.ve Tel:
[Freeipa-users] Solaris Clients
Hello, I have recently been working on integrating our solaris 10 fleet with FreeIPA. The first 'test' host went relatively smoothly and we recently created a new test host. Only this time it was more challenging to get the system working. On our original test installation every step went almost exactly as per the documentation [ http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html ] On the second install we found that whilst we were able to retrieve user account information via LDAP we could not login via ssh and kerberos for any amount of trying. This was overcome by inserting the following line into pam.conf other accountsufficient pam_ldap.so.1 Where is had not been needed on test host1. To the extent it works and doesn't break something else this is all fine. I understand why it works as the information in ldap is needed to open the terminal session, why would one need this stanza but not the other? If anyone can shed any light on this I would be most appreciative. Thanks ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Solaris Clients
On Wed, Mar 13, 2013 at 3:39 PM, Luke Kearney l...@kearney.jp wrote: Hello, I have recently been working on integrating our solaris 10 fleet with FreeIPA. The first 'test' host went relatively smoothly and we recently created a new test host. Only this time it was more challenging to get the system working. On our original test installation every step went almost exactly as per the documentation [ http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html ] On the second install we found that whilst we were able to retrieve user account information via LDAP we could not login via ssh and kerberos for any amount of trying. This was overcome by inserting the following line into pam.conf other accountsufficient pam_ldap.so.1 Where is had not been needed on test host1. To the extent it works and doesn't break something else this is all fine. I understand why it works as the information in ldap is needed to open the terminal session, why would one need this stanza but not the other? IIRC, the instructions have you pulling information from Kerberos. This explicitly allows ldap -- I would suspect that Kerberos isn't working correctly on the second host. Check time first. -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] squid problems when upgrading to 6.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/13/2013 09:20 PM, Natxo Asenjo wrote: hi, following the howto http://freeipa.org/page/Squid_Integration_with_FreeIPA_using_Single_Sign_On I had setup squid. Tonight running the updates the changes to the init script http://freeipa.org/page/Squid_Integration_with_FreeIPA_using_Single_Sign_On#Change_the_.2Fetc.2Finit.d.2Fsquid_startup_script_to_read_in_the_keytab_on_service_start. were gone and so the internet was not working. Not nice. The howto should specify that the config must come in /etc/sysconfig/squid instead. Then the upgrade has no nasty consequences. So /etc/sysconfig/squid should look like this: # default squid options SQUID_OPTS= # Time to wait for Squid to shut down when asked. Should not be necessary # most of the time. SQUID_SHUTDOWN_TIMEOUT=100 # default squid conf file SQUID_CONF=/etc/squid/squid.conf # kerberos stuff KRB5_KTNAME=/etc/squid/krb5.keytab export KRB5_KTNAME Hi Natxo I've just deployed a RHEL 6.4 proxy and the guide is still accurate and works.. however I agree a config file would be a better place for the options. Both work at the end of the day. I'm more curious as to why your squid init script was replaced instead of the usual scenario of having the new file saved as .rpmsave. By the way, I came accross http://squidkerbauth.sourceforge.net/ squid_kerb_ldap to allow/block stuff in the proxy depending on ldap group membership. I have not tested it yet, but will post it if(when) I get it working. You can also check out SquidGuard, which is available in EPEL. I've written an article for Active Directory, however it is just as easy to use it with IPA. https://www.dalemacartney.com/2012/07/06/web-proxy-filtering-with-squidguard-using-active-directory-group-memberships/ -- Groeten, natxo ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRQPN6AAoJEAJsWS61tB+qG8kQAJU3bKwnzwWoiD5jhl0CM6jq 3n2GnbRLY8AIO3wuSKeyaLi1IHq/DcpLME85bcR/6JqM2PaqcDs0J1swhF8Z8436 5UWqVsnsdWKP/oamY4XAI7E+gZHE0eggNPgq8a7rYX/97epmPpZTBSfGDEYkJEMZ tJx3DrATvvmJ97c6XzASgbjd8D459a7MBilxyUf5+w4yexlqmxcxyb3dezgZ+mgT MHP7Ex7i7+2sWsBQb2E72CeqoLrwsgTgMT8Ywl5E5m5w2atstUTGCKUSt7uem+o1 xeD4z2hUp6GEzy+IeHf/Ro/dvzax7t0+Ya32doWXozKvYMU6qk6fmqQWjw07EJME oo4FIAy3b5tjDCrvve/JRYTsbOXdLYEMZx6fRb65gbplbgxK/R0Yp6V5BQHgesqF 3nCLQv8iBAzeokPg0VOysKOkfhHvRqX+q1hB0FgDMIRCgzpqPdOAb4I6SeInttah hKoPfnp6njGmOTlCqKccLq5RyZMTbvxlJ2hcNoYVwGpftUkY4I0dsUAXDoQ8UDyk xQ/QsDMO+3oMX+4yynJm3/I3AQltOMXZUliJDz99fcyRbLI3pV0eJybumrLuHdxA 7+/CokuFHAcchjWS19BGuOn3a6NWXTG2qmisZgaoVc8k3Uwi2PLp4puJQBtlY5o0 6Np35uYyfdcWZC3jIhTg =5DAX -END PGP SIGNATURE- ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Solaris Clients
I'm not sure if this will help (not being a Solaris shop), but when we rolled out IPA in our environment, I had some trouble with ssh and kerberos auth working correctly. As it turned out, the fix was adding reverse lookup records (PTR) in the DNS for all the servers. -Mike -Original Message- From: Luke Kearney l...@kearney.jp Sent: Mar 13, 2013 4:39 PM To: Freeipa-users@redhat.com Subject: [Freeipa-users] Solaris Clients Hello, I have recently been working on integrating our solaris 10 fleet with FreeIPA. The first 'test' host went relatively smoothly and we recently created a new test host. Only this time it was more challenging to get the system working. On our original test installation every step went almost exactly as per the documentation [ http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html ] On the second install we found that whilst we were able to retrieve user account information via LDAP we could not login via ssh and kerberos for any amount of trying. This was overcome by inserting the following line into pam.conf other accountsufficient pam_ldap.so.1 Where is had not been needed on test host1. To the extent it works and doesn't break something else this is all fine. I understand why it works as the information in ldap is needed to open the terminal session, why would one need this stanza but not the other? If anyone can shed any light on this I would be most appreciative. Thanks ___ 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] squid problems when upgrading to 6.4
On Wed, Mar 13, 2013 at 10:45 PM, Dale Macartney d...@themacartneyclan.com wrote: I've just deployed a RHEL 6.4 proxy and the guide is still accurate and works.. however I agree a config file would be a better place for the options. Both work at the end of the day. yes, the guide is accurate, but upgrading to meet a bunch of angry users is not nice ;-) I'm more curious as to why your squid init script was replaced instead of the usual scenario of having the new file saved as .rpmsave. beats me. Anyway, config stuff should go in /etc/sysconfig, period ;-) ; we should not be touching the init scripts. The init scripts source the files in /etc/sysconfig/* By the way, I came accross http://squidkerbauth.sourceforge.net/ squid_kerb_ldap to allow/block stuff in the proxy depending on ldap group membership. I have not tested it yet, but will post it if(when) I get it working. You can also check out SquidGuard, which is available in EPEL. ha, squid_kerb_ldap is not a proxy, it is an authenticator for squid and what it does is verify the group membership of the users so you can build ACLs based on that. squidguard is nice. I like privoxy too ;-) I've written an article for Active Directory, however it is just as easy to use it with IPA. https://www.dalemacartney.com/2012/07/06/web-proxy-filtering-with-squidguard-using-active-directory-group-memberships/ cool, thanks. -- natxo ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Solaris Clients
On Mar 14, 2013, at 6:38 AM, KodaK wrote: On Wed, Mar 13, 2013 at 3:39 PM, Luke Kearney l...@kearney.jp wrote: Hello, I have recently been working on integrating our solaris 10 fleet with FreeIPA. The first 'test' host went relatively smoothly and we recently created a new test host. Only this time it was more challenging to get the system working. On our original test installation every step went almost exactly as per the documentation [ http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html ] On the second install we found that whilst we were able to retrieve user account information via LDAP we could not login via ssh and kerberos for any amount of trying. This was overcome by inserting the following line into pam.conf other accountsufficient pam_ldap.so.1 Where is had not been needed on test host1. To the extent it works and doesn't break something else this is all fine. I understand why it works as the information in ldap is needed to open the terminal session, why would one need this stanza but not the other? IIRC, the instructions have you pulling information from Kerberos. This explicitly allows ldap -- I would suspect that Kerberos isn't working correctly on the second host. Check time first. Thanks for that - NTP reports that both the kerberos master and the solaris client are indeed in sync. In all other respects kerberos seems to be working properly, a user can obtain a ticket and can use that same ticket to ssh to another host. -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Realm distrubuted across data centers
El mié, 13-03-2013 a las 15:57 -0400, Simo Sorce escribió: On Wed, 2013-03-13 at 14:36 -0430, Loris Santamaria wrote: El mié, 13-03-2013 a las 14:44 +0100, Petr Spacek escribió: On 13.3.2013 14:28, Rob Crittenden wrote: Michael ORourke wrote: I think SRV records are only part of the problem. We are using integrated BIND/DNS with our IPA servers and I'm not sure it supports views. But thanks for the suggestion. I guess we could create custom krb5.conf files in each DC and mange them with Puppet, but there are other config files (e.g. resolv.conf and ldap.conf) that would need to be managed too. Maybe there are some other IPA client config files that setup static mappings during the join process. Anyone know which ones to look at? No, we don't support views yet. Views are not supported in IPA admin tools, but generally views can be configured with some hacking around. The price for that is losing IPA admin tools for DNS and generally, it is ugly and hard to maintain. I wouldn't recommend that. Our latest greatest proposal for location auto-discovery in summarized at http://www.freeipa.org/page/V3/DNS_Location_Mechanism . Any comments are welcome! Hi! The proposal seems to me too complicated, I really liked the old proposal where you could query the DNS which was the most appropriate site for your IP address. Choosing the right site by IP address is not perfect, there will be always some corner cases, but it is good enough and way better than what we have now. Can you explain what is complicated about the current proposal ? The reason I thought hard about this one is that the previous proposal would require * a lot* of work on both client and server and was, as you note, not great. The current proposal is a lot easier to implement both on the server and the client and reduces considerably the amount of code for both, especially for the client, where in many case no changes are required at all, just a client reconfiguration. Maybe I don't get the proposal completely but these dynamically generated DNAME record which won't work when you need them the most (when you are a roaming user querying a non-ipa DNS server...) don't seem very helpful. The complicated part seems to me all the magic (or rather, policy) that would go into bind-dyndb-ldap, which can not be easily modified by the admin, and as you note in the proposal DNSSEC interaction is problematic. In general DNSSEC doesn't play well with views and with dynamically generated records. What if the company doesn't want to manage their DNS with IPA? What if the user is outside the company's network? What if the user is connecting to the company's network via vpn but is using the DNS servers of his ISP? Your first proposal, even if it required the admin to add some info in the server (site list, servers per site, ip networks per site) would work even outside the company's firewall, could be managed with any dns server and would play well with DNSSEC. Loris The problem could be addressed in two parts: 1) Add the concepts of sites to the IPA realm, and associate every server with one (and just one?) site, the generate the appropriate SRV record for every site. I did this manually, creating the SRV records one by one: _kerberos._udp.site1._sites.mydomain.com. IN SRV 0 100 88 ipa1.mydomain.com. ... When joining the host to the domain the admin may add the option --domain=site1._sites.mydomain.com to ipa-client-install to use the right ipa servers for that site. This first step could be added to IPA fairly easy and it would be a great improvement. 2) Add some kind of configurable locator policy to SSSD. There could be: 2.1) fixed site policy, which would use always the same site 2.2) CLDAP ping AD-like policy 2.3) a policy which reads and remember the right site per client or per ip address from LDAP on first connection... The problem with this is that you need to explicitly configure the client, and invent these new things in SSSD. In our new proposal you do not need to do anything on the client, except pointing it to ... itself! So I am a bit confused about why you say the new proposal would be more complicated ... Simo. -- Loris Santamaria linux user #70506 xmpp:lo...@lgs.com.ve Links Global Services, C.A.http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:1...@lgs.com.ve If I'd asked my customers what they wanted, they'd have said a faster horse - Henry Ford smime.p7s Description: S/MIME cryptographic signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
