Re: [Freeipa-users] Replication stopped working
I should add that we already tried everything at https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html On Thu, Sep 4, 2014 at 11:11 AM, Guillermo Fuentes guillermo.fuen...@modernizingmedicine.com wrote: Hello list, We’re running FreeIPA with a master and 3 replicas. The replication stopped working and currently we’re adding resources only to the master. This is the environment we have: m1: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 CA: pki-ca-9.0.3 # ipa-replica-manage list -v `hostname` m2.example.com: replica last init status: None last init ended: None last update status: 49 - LDAP error: Invalid credentials last update ended: None m3.example.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-04 14:28:44+00:00 m4.example.com: replica last init status: None last init ended: None last update status: -2 - LDAP error: Local error last update ended: None m2: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: -1 Incremental update has failed and requires administrator actionLDAP error: Can't contact LDAP server last update ended: 2014-09-03 22:53:21+00:00 m3: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-04 14:31:51+00:00 m4: OS: CentOS release 6.5 FreeIPA: 3.3.3-28 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: 49 Unable to acquire replicaLDAP error: Invalid credentials last update ended: None Note that although m3 reports “Incremental update succeeded”, users created on m1 are not replicated to m3, and users created on m3 are not replicated back to m1. We’ve tried different things including re-initializing m2. Can somebody point me in the right direction to get replication going again? Thanks in advance! Guillermo -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Cheers, Fredy Sanchez IT Manager @ Modernizing Medicine 561-880-2998 x237 fredy.sanc...@modmed.com Need IT support? Visit https://mmit.zendesk.com - - -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Replication stopped working
sudo ipa-replica-conncheck --replica for all replicas comes back with ... The following UDP ports could not be verified as open: 88, 464 This can happen if they are already bound to an application and ipa-replica-conncheck cannot attach own UDP responder. Connection from master to replica is OK. ipa-replica-manage -v list $REPLICA fails w/ Failed to get data from 'REPLICA': Invalid credentials SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context The common error is: nsds5replicaLastUpdateStatus: -2 - LDAP error: Local error On Thu, Sep 4, 2014 at 11:21 AM, Fredy Sanchez fredy.sanc...@modmed.com wrote: I should add that we already tried everything at https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html On Thu, Sep 4, 2014 at 11:11 AM, Guillermo Fuentes guillermo.fuen...@modernizingmedicine.com wrote: Hello list, We’re running FreeIPA with a master and 3 replicas. The replication stopped working and currently we’re adding resources only to the master. This is the environment we have: m1: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 CA: pki-ca-9.0.3 # ipa-replica-manage list -v `hostname` m2.example.com: replica last init status: None last init ended: None last update status: 49 - LDAP error: Invalid credentials last update ended: None m3.example.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-04 14:28:44+00:00 m4.example.com: replica last init status: None last init ended: None last update status: -2 - LDAP error: Local error last update ended: None m2: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: -1 Incremental update has failed and requires administrator actionLDAP error: Can't contact LDAP server last update ended: 2014-09-03 22:53:21+00:00 m3: OS: CentOS release 6.5 FreeIPA: 3.0.0-37 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-09-04 14:31:51+00:00 m4: OS: CentOS release 6.5 FreeIPA: 3.3.3-28 # ipa-replica-manage list -v `hostname` m1.example.com: replica last init status: None last init ended: None last update status: 49 Unable to acquire replicaLDAP error: Invalid credentials last update ended: None Note that although m3 reports “Incremental update succeeded”, users created on m1 are not replicated to m3, and users created on m3 are not replicated back to m1. We’ve tried different things including re-initializing m2. Can somebody point me in the right direction to get replication going again? Thanks in advance! Guillermo -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Cheers, Fredy Sanchez IT Manager @ Modernizing Medicine 561-880-2998 x237 fredy.sanc...@modmed.com Need IT support? Visit https://mmit.zendesk.com - - -- Cheers, Fredy Sanchez IT Manager @ Modernizing Medicine 561-880-2998 x237 fredy.sanc...@modmed.com Need IT support? Visit https://mmit.zendesk.com - - -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] [SOLVED] Re: FreeIPA backend. Mavericks server shows UIDs instead of usernames in File Sharing.
Hi Davis, We tried to get this working for a couple of days, but gave up. It is actually better for us to have our users reset their FreeIPA passwords only from the web interface. On Fri, Jun 27, 2014 at 1:23 PM, Davis Goodman davis.good...@digital-district.ca wrote: Hi Fredy, We have integrated our Mac Worstations (Mountain Lion and Maverick) with FreeIPA with good success except for password change. Does your method allows users to change their password through the OSX interface for example when a new user is created and logs in for the first time? For now we need to have our users go through the web interface of a different workstation to change their newly created account password. At this point that is the only thing that still doesn’t work for us. Davis Davis Goodman Directeur Informatique | IT Manager [image: Digital-District] http://www.digital-district.ca/ 5605 Avenue de Gaspé, Suite 408 | Montréal, QC H2T 2A4 From: Simo Sorce s...@redhat.com Reply: Simo Sorce s...@redhat.com Date: April 16, 2014 at 18:06:27 To: Fredy Sanchez fredy.sanc...@modmed.com Cc: Guillermo Fuentes guillermo.fuen...@modernizingmedicine.com, freeipa-users@redhat.com freeipa-users@redhat.com Subject: [Freeipa-users] [SOLVED] Re: FreeIPA backend. Mavericks server shows UIDs instead of usernames in File Sharing. Good! And thanks for letting us know, it may help other users too. Simo. On Wed, 2014-04-16 at 17:58 -0400, Fredy Sanchez wrote: Hi Simo, Thanks for your reply. Good old Google pointed me to https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/open-ldap_bind_script/Mac_OpenLDAP_bind_script.sh, which gave me the idea of updating the RealName mapping to displayName. This solved the problem, I'll have to recreate the permissions for every share, but the user names now show up, and stick. No more UIDs. On Tue, Apr 15, 2014 at 9:30 AM, Simo Sorce s...@redhat.com wrote: On Fri, 2014-04-11 at 10:37 -0400, Fredy Sanchez wrote: Hi all, We asked this same question at discussions.apple.com, but figured we'd have better luck here. I apologize in advance if this is the wrong forum. We are switching from Synology (DSM 5) to Mavericks server (v3.1.1. running in Mavericks 10.9.2) for File Sharing. We use a FreeIPA (ipa-server.x86_64 3.0.0-37.el6) backend for SSO, and the Mac server seems correctly bound to it. Unfortunately, although we can add usernames to the shares for the initial config, the usernames transform to UIDs after (only for SSO accounts; local accounts are not affected). That is, when we go to edit the permissions for a share, all we see are UIDs. We can always figure out the username from the UID, but this is an extra step we don't want to have. We've tried reinstalling the Mac server app from scratch, re-binding to the FreeIPA backend, changing mappings in Directory Utility (for example, mapping GeneratedUID to uid, which is the username), recreating the shares and permissions, etc. Here are more details about the binding: * The binding happens thru a custom package we created based primarily on http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 * Sys Prefs, Users Groups, Login Options show the server bound to the FreeIPA backend with the green dot * The following mappings are in place in Directory Utility, Services, LDAPv3, FreeIPA backend Users: inetOrgPerson AuthenticationAuthority: uid GeneratedUID: random number in uppercase HomeDirectory: #/Users/$uid$ NFSHomeDirectory: #/Users/$uid$ OriginalHomeDirectory: #/Users/$uid$ PrimaryGroupID: gidNumber RealName: cn RecordName: uid UniqueID: uidNumber UserShell: loginShell Groups: posixgroup PrimaryGroupID: gidNumber RecordName: cn The search bases are correct * Directory Utility, Directory Editor shows the right info for the users. * $ id $USERNAME shows the right information for the user FreeIPA is working beautifully for our Mac / Linux environment. We provide directory services to about 300 hosts, and 200 employees using it; and haven't had any problems LDAP wise until now. So we think we are missing a mapping here. Any ideas? Fredy, I quickly tried to check for some documentation on how to configure this stuff, but found only useless superficial guides on how to find the pointy/clicky buttons to push to enable the service. I am not a Mac expert by a long shot so I cannot help you much here. Is there any guide available on how to use this service with other LDAP servers, like openLDAP or Active Directory ? We can probably draw some conclusions from there. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Simo Sorce * Red Hat, Inc * New York
Re: [Freeipa-users] FreeIPA backend. Mavericks server shows UIDs instead of usernames in File Sharing.
Hi all, Sorry for the delay. I am sharing with you a couple of scripts and files we use to enroll our Macs (ML and Mavericks) into our FreeIPA domain. Using Luggage ( https://github.com/unixorn/luggage), we package all of these into a one click installer that can be deployed via ARD, Munki, etc. Now, our environment has very specific requirements, so feel free to ask if there's something you don't understand or that seems incomplete. These assume you already know what FreeIPA is, and have it up and running. These also assume that all the server pre-staging (for example, that all applicable DNS records are already created) for the enrollee is done. In sum, these are ideal if all you are missing is to start enrolling Macs into the FreeIPA domain. And you'll have to modify the files to match your FreeIPA domain; we are using example.com for this. The preflight script (freeipa-client-preinstall.sh) will clean the environment of the enrollee, and backup existing files that will be modified during the enrollment process. It * Sets the DNS search domain * Adds a local search domain to the enrollee to speed up the login process if no FreeIPA server is available during login * Backs up edu.mit.Kerberos if it exists * Backs up krb5.conf if it exists * Backs up any existing LDAP info * Backs up /Library/Preferences/com.apple.loginwindow.plist The postflight script (freeipa-client-postinstall.sh) performs the enrollment. It * Sets email notifications to know if the enrollment failed or succeeded. These notifications will include the who and the why, and a hardware profile from the enrollee that we find useful * Sets and tests many variables needed for a successful enrollment like NTP syncing, a valid hostname, and whether or not all applicable hosts resolve thru your DNS servers * Adjusts /Library/Preferences/com.apple.loginwindow to work properly w/ FreeIPA accounts * Gets opendirectoryd ready for FreeIPA * Enrolls the host to FreeIPA thru multiple keytab manipulations * Gets around problems with anonymous binds in LDAP by using a hidden user for enrollments * Configures the SSH client for GSSAPI authentication * Creates host keys and adds them to FreeIPA * Deletes local user account and leaves home directory intact. This will allow the owner of the machine to log back in using his/her FreeIPA credentials w/out noticing any changes. Of course, for this to happen transparently the home directory has to be massaged. Please let me know if you'd like to know how we do this. I am omitting the details for now as this outside the scope, me thinks. The files inside the Payload folder are: The authorization and screensaver files are FreeIPA ready ones. The postflight script above puts them where they need to go (/private/etc/pam.d). The postflight will add a /private/etc/ipa folder to the enrollee. This folder must contain the following files: ca-crt, ca-crt-selfsigned, example.enroll.keytab. These will make more sense as you go thru the code. These are private, so I am not sharing them. The postflight script will also put FreeIPA ready versions of edu.mit.Kerberos and multiple LDAP config files where they need to go (follow the folder structure in the .zip file attached). These we are sharing; you will have to modify them to match your FreeIPA domain. And this is it. Apologies for the long read. We welcome your feedback; if you have any please send it my way :-) On Thu, Apr 17, 2014 at 4:29 PM, Chris Whittle cwhi...@gmail.com wrote: I was able to take that script and with some customizing get it to work with Mavericks This should work, I tried to do a find and replace to make it work like the github one. On Wed, Apr 16, 2014 at 5:40 PM, Fredy Sanchez fredy.sanc...@modmed.comwrote: Sure Rob, we'll put something together and send it to you for publishing. Give us a few days. We'll also sanitize our enrollment package and share it w/ you too. This is what we use to enroll our Macs, a one time install that does what ipa-client-install does for Linux, including these LDAP mappings. We love FreeIPA and will be really happy if this helps any other users with Mac fleets. On Wed, Apr 16, 2014 at 6:12 PM, Rob Crittenden rcrit...@redhat.comwrote: Fredy Sanchez wrote: Hi Simo, Thanks for your reply. Good old Google pointed me to https://github.com/rtrouton/rtrouton_scripts/blob/master/ rtrouton_scripts/open-l dap_bind_script/Mac_OpenLDAP_bind_script.sh, which gave me the idea of updating the RealName mapping to displayName. This solved the problem, I'll have to recreate the permissions for every share, but the user names now show up, and stick. No more UIDs. Great. Any chance you can write something and post a howto on our wiki? Or send the details to me and I'll write something up? thanks rob On Tue, Apr 15, 2014 at 9:30 AM, Simo Sorce s...@redhat.com mailto:s...@redhat.com wrote: On Fri, 2014-04-11 at 10:37 -0400, Fredy Sanchez wrote: Hi all, We
Re: [Freeipa-users] FreeIPA backend. Mavericks server shows UIDs instead of usernames in File Sharing.
Sure Rob, we'll put something together and send it to you for publishing. Give us a few days. We'll also sanitize our enrollment package and share it w/ you too. This is what we use to enroll our Macs, a one time install that does what ipa-client-install does for Linux, including these LDAP mappings. We love FreeIPA and will be really happy if this helps any other users with Mac fleets. On Wed, Apr 16, 2014 at 6:12 PM, Rob Crittenden rcrit...@redhat.com wrote: Fredy Sanchez wrote: Hi Simo, Thanks for your reply. Good old Google pointed me to https://github.com/rtrouton/rtrouton_scripts/blob/master/ rtrouton_scripts/open-l dap_bind_script/Mac_OpenLDAP_bind_script.sh, which gave me the idea of updating the RealName mapping to displayName. This solved the problem, I'll have to recreate the permissions for every share, but the user names now show up, and stick. No more UIDs. Great. Any chance you can write something and post a howto on our wiki? Or send the details to me and I'll write something up? thanks rob On Tue, Apr 15, 2014 at 9:30 AM, Simo Sorce s...@redhat.com mailto:s...@redhat.com wrote: On Fri, 2014-04-11 at 10:37 -0400, Fredy Sanchez wrote: Hi all, We asked this same question at discussions.apple.com http://discussions.apple.com, but figured we'd have better luck here. I apologize in advance if this is the wrong forum. We are switching from Synology (DSM 5) to Mavericks server (v3.1.1. running in Mavericks 10.9.2) for File Sharing. We use a FreeIPA (ipa-server.x86_64 3.0.0-37.el6) backend for SSO, and the Mac server seems correctly bound to it. Unfortunately, although we can add usernames to the shares for the initial config, the usernames transform to UIDs after (only for SSO accounts; local accounts are not affected). That is, when we go to edit the permissions for a share, all we see are UIDs. We can always figure out the username from the UID, but this is an extra step we don't want to have. We've tried reinstalling the Mac server app from scratch, re-binding to the FreeIPA backend, changing mappings in Directory Utility (for example, mapping GeneratedUID to uid, which is the username), recreating the shares and permissions, etc. Here are more details about the binding: * The binding happens thru a custom package we created based primarily on http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7. 2F10.8 * Sys Prefs, Users Groups, Login Options show the server bound to the FreeIPA backend with the green dot * The following mappings are in place in Directory Utility, Services, LDAPv3, FreeIPA backend Users: inetOrgPerson AuthenticationAuthority: uid GeneratedUID: random number in uppercase HomeDirectory: #/Users/$uid$ NFSHomeDirectory: #/Users/$uid$ OriginalHomeDirectory: #/Users/$uid$ PrimaryGroupID: gidNumber RealName: cn RecordName: uid UniqueID: uidNumber UserShell: loginShell Groups: posixgroup PrimaryGroupID: gidNumber RecordName: cn The search bases are correct * Directory Utility, Directory Editor shows the right info for the users. * $ id $USERNAME shows the right information for the user FreeIPA is working beautifully for our Mac / Linux environment. We provide directory services to about 300 hosts, and 200 employees using it; and haven't had any problems LDAP wise until now. So we think we are missing a mapping here. Any ideas? Fredy, I quickly tried to check for some documentation on how to configure this stuff, but found only useless superficial guides on how to find the pointy/clicky buttons to push to enable the service. I am not a Mac expert by a long shot so I cannot help you much here. Is there any guide available on how to use this service with other LDAP servers, like openLDAP or Active Directory ? We can probably draw some conclusions from there. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Cheers, Fredy Sanchez IT Manager @ Modernizing Medicine (561) 880-2998 x237 fredy.sanc...@modmed.com mailto:fredy.sanc...@modmed.com *Need IT support?* Visit https://mmit.zendesk.com https://mmit.zendesk.com/ * * * * ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Cheers, Fredy Sanchez IT Manager @ Modernizing Medicine (561) 880-2998 x237 fredy.sanc...@modmed.com *Need IT support?* Visit https://mmit.zendesk.com
Re: [Freeipa-users] FreeIPA backend. Mavericks server shows UIDs instead of usernames in File Sharing.
Hi Simo, Thanks for your reply. Good old Google pointed me to https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/open-ldap_bind_script/Mac_OpenLDAP_bind_script.sh, which gave me the idea of updating the RealName mapping to displayName. This solved the problem, I'll have to recreate the permissions for every share, but the user names now show up, and stick. No more UIDs. On Tue, Apr 15, 2014 at 9:30 AM, Simo Sorce s...@redhat.com wrote: On Fri, 2014-04-11 at 10:37 -0400, Fredy Sanchez wrote: Hi all, We asked this same question at discussions.apple.com, but figured we'd have better luck here. I apologize in advance if this is the wrong forum. We are switching from Synology (DSM 5) to Mavericks server (v3.1.1. running in Mavericks 10.9.2) for File Sharing. We use a FreeIPA (ipa-server.x86_64 3.0.0-37.el6) backend for SSO, and the Mac server seems correctly bound to it. Unfortunately, although we can add usernames to the shares for the initial config, the usernames transform to UIDs after (only for SSO accounts; local accounts are not affected). That is, when we go to edit the permissions for a share, all we see are UIDs. We can always figure out the username from the UID, but this is an extra step we don't want to have. We've tried reinstalling the Mac server app from scratch, re-binding to the FreeIPA backend, changing mappings in Directory Utility (for example, mapping GeneratedUID to uid, which is the username), recreating the shares and permissions, etc. Here are more details about the binding: * The binding happens thru a custom package we created based primarily on http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 * Sys Prefs, Users Groups, Login Options show the server bound to the FreeIPA backend with the green dot * The following mappings are in place in Directory Utility, Services, LDAPv3, FreeIPA backend Users: inetOrgPerson AuthenticationAuthority: uid GeneratedUID: random number in uppercase HomeDirectory: #/Users/$uid$ NFSHomeDirectory: #/Users/$uid$ OriginalHomeDirectory: #/Users/$uid$ PrimaryGroupID: gidNumber RealName: cn RecordName: uid UniqueID: uidNumber UserShell: loginShell Groups: posixgroup PrimaryGroupID: gidNumber RecordName: cn The search bases are correct * Directory Utility, Directory Editor shows the right info for the users. * $ id $USERNAME shows the right information for the user FreeIPA is working beautifully for our Mac / Linux environment. We provide directory services to about 300 hosts, and 200 employees using it; and haven't had any problems LDAP wise until now. So we think we are missing a mapping here. Any ideas? Fredy, I quickly tried to check for some documentation on how to configure this stuff, but found only useless superficial guides on how to find the pointy/clicky buttons to push to enable the service. I am not a Mac expert by a long shot so I cannot help you much here. Is there any guide available on how to use this service with other LDAP servers, like openLDAP or Active Directory ? We can probably draw some conclusions from there. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Cheers, Fredy Sanchez IT Manager @ Modernizing Medicine (561) 880-2998 x237 fredy.sanc...@modmed.com *Need IT support?* Visit https://mmit.zendesk.com - - ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] FreeIPA backend. Mavericks server shows UIDs instead of usernames in File Sharing.
Hi all, We asked this same question at discussions.apple.com, but figured we'd have better luck here. I apologize in advance if this is the wrong forum. We are switching from Synology (DSM 5) to Mavericks server (v3.1.1. running in Mavericks 10.9.2) for File Sharing. We use a FreeIPA (ipa-server.x86_64 3.0.0-37.el6) backend for SSO, and the Mac server seems correctly bound to it. Unfortunately, although we can add usernames to the shares for the initial config, the usernames transform to UIDs after (only for SSO accounts; local accounts are not affected). That is, when we go to edit the permissions for a share, all we see are UIDs. We can always figure out the username from the UID, but this is an extra step we don't want to have. We've tried reinstalling the Mac server app from scratch, re-binding to the FreeIPA backend, changing mappings in Directory Utility (for example, mapping GeneratedUID to uid, which is the username), recreating the shares and permissions, etc. Here are more details about the binding: * The binding happens thru a custom package we created based primarily on http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 * Sys Prefs, Users Groups, Login Options show the server bound to the FreeIPA backend with the green dot * The following mappings are in place in Directory Utility, Services, LDAPv3, FreeIPA backend Users: inetOrgPerson AuthenticationAuthority: uid GeneratedUID: random number in uppercase HomeDirectory: #/Users/$uid$ NFSHomeDirectory: #/Users/$uid$ OriginalHomeDirectory: #/Users/$uid$ PrimaryGroupID: gidNumber RealName: cn RecordName: uid UniqueID: uidNumber UserShell: loginShell Groups: posixgroup PrimaryGroupID: gidNumber RecordName: cn The search bases are correct * Directory Utility, Directory Editor shows the right info for the users. * $ id $USERNAME shows the right information for the user FreeIPA is working beautifully for our Mac / Linux environment. We provide directory services to about 300 hosts, and 200 employees using it; and haven't had any problems LDAP wise until now. So we think we are missing a mapping here. Any ideas? -- Cheers, Fredy Sanchez IT Manager @ Modernizing Medicine (561) 880-2998 x237 fredy.sanc...@modmed.com *Need IT support?* Visit https://mmit.zendesk.com - - ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
