[Freeipa-users] RHEL 5.x client functionality with ipa-server 3.0
Hello All, We have a mixed RHEL environment (5.x, 6.x, x86, and x86_64). Our FreeIPA server is running RHEL 6.4 x86_64 with ipa-server 3.0. My question is what are the hurdles or feature limitations should I expect to encounter in this mixed environment, especially in regards to the RHEL 5.x systems? I appreciate any feedback or experience provided. Thanks, Brian ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Restrict AD users from passwd
Hi All, Our current account management policy requires that users change their AD passwords via a special portal, however I've noticed that this can be bypassed by issuing passwd on a Linux system while logged in with AD credentials, thus changing their AD password. Any thoughts on the best way to prevent this action? What I've considered so far is removing the trust in AD, effectively creating a one-way trust, but that would limit functionality for future interoperability. Additionally, we could change the permissions for passwd on each Linux system, but this would be somewhat hackish and also complicated to enforce, since we're waiting on Foreman + Puppet to properly be integrated into Katello for our configuration management solution. Any way to restrict this via the FreeIPA UI? Thanks, Brian ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Restrict AD users from passwd
Hi Sumit, Thanks for the suggestion. I'll have to give this some thought, since we have 100+ AD servers, this might not be well received by the AD team. If anyone can think of a better mousetrap than this, let me know. Thanks, Brian On Wed, Aug 14, 2013 at 9:37 AM, Sumit Bose sb...@redhat.com wrote: On Wed, Aug 14, 2013 at 09:19:17AM -0400, Brian Lee wrote: Hi All, Our current account management policy requires that users change their AD passwords via a special portal, however I've noticed that this can be bypassed by issuing passwd on a Linux system while logged in with AD credentials, thus changing their AD password. Any thoughts on the best way to prevent this action? What I've considered so far is removing the trust in AD, effectively creating a one-way trust, but that would limit functionality for future interoperability. Additionally, we could change the permissions for passwd on each Linux system, but this would be somewhat hackish and also complicated to enforce, since we're waiting on Foreman + Puppet to properly be integrated into Katello for our configuration management solution. Any way to restrict this via the FreeIPA UI? I think the only safe way to achieve this is to block port 464 on the AD servers for the Linux hosts. Because basically what passwd is doing here via SSSD is to change the Kerberos password. The same can be done with the kpasswd command, it does not require any privileges the user only needs to know his current password. So even if we add an option to force SSSD to reject password changes for users from trusted domains there are other ways for users to change the password which cannot be controlled by IPA. Please note that changing the AD password with kpasswd would even work without trust. HTH bye, Sumit Thanks, Brian ___ 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
Re: [Freeipa-users] Restrict AD users from passwd
On the AD side, they limit the potential to change the AD password by deploying a modified the msgina.dll. Otherwise, the user still has the ways to throw a wrench in the system, we're just doing our best to limit the opportunity for this action. On Wed, Aug 14, 2013 at 10:32 AM, Simo Sorce s...@redhat.com wrote: On Wed, 2013-08-14 at 09:48 -0400, Brian Lee wrote: Hi Sumit, Thanks for the suggestion. I'll have to give this some thought, since we have 100+ AD servers, this might not be well received by the AD team. If anyone can think of a better mousetrap than this, let me know. Do you also block the 'net user' command on Windows clients ? It's the same as 'passwd' on Linux clients. I would address the problem by using proper password policies as I (now) see Petr recommended i another email. 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] Blocking 389 and 636 for AD trusts
Hello everyone, I understand this is well documented that we need to block AD from establishing communication to the LDAP ports, but I've never heard an explanation on why this is needed. Additionally, In our environment, we have a 100+ AD servers. Do I need to add an iptables rule for each AD server, on each IPA server or only the ones configured for DNS forwarding? Thanks as always ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Mountain Lion GUI Login
Hi Lynn, I just checked this in my lab setup: - Set up a new user on the FreeIPA server as 'ipatest'. - Logged in to a Linux client configured for FreeIPA, it prompted me to change my password. - Successfully changed my password for ipatest. Verified this on another machine. - Furthermore, I reset the Password Policy min lifetime to 0 and typed passwd on one of the ipa clients while logged in as ipatest. This worked without issue. I also have FreeIPA set up in the lab with a domain trust to a 2008 R2 AD server, so I checked to see if the results would be the same. - Logged in to FreeIPA client machine as the AD user. - Typed passwd, and successfully reset my password. Verified the change in Windows as well as another IPA client. All Linux systems in this test are running CentOS 6.4 x86_64 FreeIPA server is running ipa-server-3.0.0-26.el6_4.4.x86_64 FreeIPA clients are running ipa-client-3.0.0-26.el6_4.4.x86_64 AD Server is running Windows 2008 R2 This won't necessarily help with the OS X problem, but maybe it assists with how it's working on Linux. Thanks, Brian On Tue, Aug 6, 2013 at 8:25 PM, Lynn Root lr...@redhat.com wrote: On Aug 6, 2013, at 4:14 PM, KodaK sako...@gmail.com wrote: On Tue, Aug 6, 2013 at 4:31 PM, Davis Goodman davis.good...@digital-district.ca wrote: Hi, I have an FreeIPA server configured, managed to configure a Mountain Lion Client for automounts and user logins. My issue is that whenever I first login with a user the New Password box shows up and even if I try to change the password the box keeps reappearing without any success. If I log onto the machine with the local admin user and try to get a ticket for this user I get a New Password prompt. From there I can change the password and I get a ticket without an issue. After that I can login through the GUI without being asked for a new password. Anyone has seen this behaviour before? That's the expected behavior. When you set the user's password as an admin, it sets the force a password change flag. Correct me if I'm wrong, but it's not expect to *not* be able to change the password on an IPA client after the initial setup, and be forced to use the IPA Server to re-set the password. Granted, the client is OSX. However, I personally have experience the inability to change a new user's password on an IPA client, and only on the IPA Server. Unfortunately, I've been trying to reproduce this and I can not. I've tried on Fedora 19, and will try on RHEL next. Davis - Can you let me know your IPA Server and IPA Client versions? As well as the OS that the IPA Server is on? Also, out of curiosity, do you have directions on how you set up the client on Mac OSX? Thanks! Lynn Root Lynn Root @roguelynn Associate Software Engineer ___ 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
