Re: [Freeipa-users] How to set passwords which never expire ?
Hi, On Tue, 12 Apr 2016, bahan w wrote: I am using FreeIPA 3.0 and I would like, for specific accounts, to set passwords unexpirables. I tried to set a pwpolicy for this with the option maxage set to 0, but it did not help and the maxage was 0 (password already expired). Is there a way, with this Ipa version, to set passwords unexpirables ? it is possible to create a password policy (tab "Policy" in the web interface) for a user group of your choice and change the password max lifetime to (e.g.) 3650 days = 10 years. That's not exactly "never expiring", but it does the trick for me (I use it for LDAP bind users). Mit freundlichen Gruessen/With best regards, --Daniel. -- 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] svnserve authentication against IPA
Hi, On Sat, 27 Jun 2015, Dmitri Pal wrote: On 06/18/2015 05:09 AM, dbisc...@hrz.uni-kassel.de wrote: I have a svnserve (Subversion 1.6.11) running on my IPA server. Currently, there's a separate user database with SASL auth: /etc/sasl2/svn.conf --- pwcheck_method: auxprop auxprop_plugin: sasldb sasldb_path: /etc/sasldb2 mech_list: DIGEST-MD5 --- XXX/testrepo/conf/svnserve.conf --- [general] anon-access = none authz-db = authz realm = MYSUBDOMAIN.MYUNIVERSITY.DE [sasl] use-sasl = true min-encryption = 128 max-encryption = 256 --- On a test system, I changed svnserve auth to saslauthd and IPA: /etc/sasl2/svn.conf --- pwcheck_method: saslauthd auxprop_plugin: ldap mech_list: PLAIN ldapdb_mech: PLAIN --- XXX/testrepo/conf/svnserve.conf --- [general] anon-access = none authz-db = authz realm = MYSUBDOMAIN.MYUNIVERSITY.DE [sasl] use-sasl = true min-encryption = 0 max-encryption = 256 --- /etc/saslauthd.conf --- ldap_servers: ldaps://localhost/ ldap_search_base: cn=users,cn=accounts,dc=MYSUBDOMAIN,dc=MYUNIVERSITY,dc=DE --- Though this setup basically works and svnserve and IPA are running on the same machine I'm unhappy with PLAIN and "min-encryption = 0". What would you suggest to improve security/enable encryption in this setup? I considered switching from svnserve to Apache, but that would imply that my users will have to get used to something new. It seems that no one on the list knows details about svn configuration so if you figure it out please share the results with the list. -- Thank you, Dmitri Pal for the record: In the meantime, I've abandoned svnserve in favour of apache. It's more complicated to set up but also more flexible. In order to make it work with IPA, one needs (something similar to) the following included the apache configuration: --- LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module modules/mod_authz_svn.so LoadModule authnz_ldap_module modules/mod_authnz_ldap.so RedirectMatch ^(/svn)$ $1/ RedirectPermanent /svn/ /home/svn/ DAV svn SVNParentPath /home/svn SVNListParentPath On SVNAutoversioning On SVNReposName "example.com SVN Repositories" SVNPathAuthz short_circuit AuthType Basic AuthName "example.com SVN Repositories" AuthBasicProvider ldap AuthLDAPBindAuthoritative on AuthLDAPBindDN "uid=sysadev,CN=users,CN=accounts,DC=example,DC=com" AuthLDAPBindPassword XX AuthLDAPURL "ldaps://ipa.example.com/CN=users,CN=accounts,DC=example,DC=com?uid,nsAccountLock?sub?(ObjectClass=*)" Require ldap-attribute nsAccountLock!="true" Require valid-user AuthzSVNAccessFile /etc/subversion/svn.acl Options +Indexes +FollowSymLinks AllowOverride All Order Allow,Deny Allow from all --- I think this is more flexible and more secure than my svnserve approach. Remarks: 1. "sysadev" is the username that I use for LDAP binding (an IPA user with a long-term password, no home directory and /sbin/nologin as login shell). 2. "/etc/subversion/svn.acl" contains the access rights for the individual SVN repos. It is similar to the "authz" files that svnserve uses. 3. apache is HTTPS-only. Mit freundlichen Gruessen/With best regards, --Daniel. -- 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
[Freeipa-users] svnserve authentication against IPA
Hi, I have a svnserve (Subversion 1.6.11) running on my IPA server. Currently, there's a separate user database with SASL auth: /etc/sasl2/svn.conf --- pwcheck_method: auxprop auxprop_plugin: sasldb sasldb_path: /etc/sasldb2 mech_list: DIGEST-MD5 --- XXX/testrepo/conf/svnserve.conf --- [general] anon-access = none authz-db = authz realm = MYSUBDOMAIN.MYUNIVERSITY.DE [sasl] use-sasl = true min-encryption = 128 max-encryption = 256 --- On a test system, I changed svnserve auth to saslauthd and IPA: /etc/sasl2/svn.conf --- pwcheck_method: saslauthd auxprop_plugin: ldap mech_list: PLAIN ldapdb_mech: PLAIN --- XXX/testrepo/conf/svnserve.conf --- [general] anon-access = none authz-db = authz realm = MYSUBDOMAIN.MYUNIVERSITY.DE [sasl] use-sasl = true min-encryption = 0 max-encryption = 256 --- /etc/saslauthd.conf --- ldap_servers: ldaps://localhost/ ldap_search_base: cn=users,cn=accounts,dc=MYSUBDOMAIN,dc=MYUNIVERSITY,dc=DE --- Though this setup basically works and svnserve and IPA are running on the same machine I'm unhappy with PLAIN and min-encryption = 0. What would you suggest to improve security/enable encryption in this setup? I considered switching from svnserve to Apache, but that would imply that my users will have to get used to something new. Mit freundlichen Gruessen/With best regards, --Daniel. -- 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] add suse 11 sp3 to ipa
Hi, On Tue, 9 Jun 2015, Rob Crittenden wrote: mohammad sereshki wrote: Would you please let me know is it possible to add suse 11 sp3 to IPA? and how it is possible? I'm not sure if any version of SUSE has ipa-client or freeipa-client, but I know that 12+ has sssd. If 11 also has sssd then you can configure that part using this: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/linux-manual.html Note that a bunch of the steps don't really apply to you, like getting a host cert. Oddly enough, the docs don't include setting up krb5.conf, but you can get the jist of that from an ipa-cleint enrolled client. If you don't have sssd then you'll need to go the nss_ldap route. I have a bunch of openSUSE 13.2 machines which work fine with sssd from standard repos (after manual installation as described in the above document - you can, however, make a powerful autoyast recipe that includes configuration files, certs and Kerberos host keys to automate the complete installation process). I recall that i had to use an extra repository for sssd and earlier versions of openSUSE Linux: http://download.opensuse.org/repositories/network:/ldap/ There seems to be indeed no sssd for SLE11 SP3, only nss_ldap. Mit freundlichen Gruessen/With best regards, --Daniel. -- 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] Unable to Rebuid Replica
Sina, On Fri, 24 Apr 2015, Sina Owolabi wrote: I noticed that my IPA domain masters were out of sync, with users having to login with different passwords depending on the IPA client they were connected to. I noticed it was the replica that was the problem, and I took it down, uninstalled IPA with a ipa-server-install --uninstall -U, deleted all the folders based on Adam Young's blog (http://adam.younglogic.com/2011/02/sterilizing-for-ipa-uninstall/) and tried to create replica again. It repeatedly fails, and I am hoping for some insight on how to fix this. Please can anyone help? I'm running this on RHEL6.6 and I just updated the entire machine. Installation logs: [...] you may have run into this issue: https://www.redhat.com/archives/freeipa-users/2015-February/msg00384.html In short: You may be missing some Apache modules on the IPA master. This problem occurs only, if you attempt to install your replica with --setup-ca, otherwise installation will work. Mit freundlichen Gruessen/With best regards, --Daniel. -- 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] Replica install fails when using --setup-ca
Hi,
for the record: The problem was a misconfigured Apache on the IPA master,
cf.
https://www.redhat.com/archives/freeipa-users/2015-February/msg00041.html
In my case, my Apache didn't load proxy_ajp_module and after this was
fixed, ipa-replica-install --setup-ca worked as expected.
Thanks to Endi Sukma Dewata and Martin Kosek for putting me on the right
track.
On Tue, 6 Jan 2015, dbisc...@hrz.uni-kassel.de wrote:
I have two small FreeIPA installations (for two different realms), both
with CentOS 6/FreeIPA 3.0.0-42. After running them both with only one
master server each for a while, I attempted to extend both installations
with one replica each.
Doing a
ipa-replica-install --setup-ca /var/lib/ipa/replica-info-...
worked fine for one of the installations, but failed for the other:
---
[...]
[3/17]: configuring certificate server instance ipa : CRITICAL failed
to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent
ConfigureCA -cs_hostname xxx -cs_port 9445 -client_certdb_dir
/tmp/tmp-YsXvhP -client_certdb_pwd -preop_pin
vJl0m3xc9Oz7b1fIgttD -domain_name IPA -admin_user admin -admin_email
root@localhost -admin_password -agent_name ipa-ca-agent
-agent_key_size 2048 -agent_key_type rsa -agent_cert_subject
CN=ipa-ca-agent,O=YYY -ldap_host xxx -ldap_port 7389 -bind_dn
cn=Directory Manager -bind_password -base_dn o=ipaca -db_name
ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA
-save_p12 true -backup_pwd -subsystem_name pki-cad -token_name
internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=YYY
-ca_subsystem_cert_subject_name CN=CA Subsystem,O=YYY
-ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=YYY
-ca_server_cert_subject_name CN=xxx,O=YYY
-ca_audit_signing_cert_subject_name CN=CA Audit,O=YYY
-ca_sign_cert_subject_name CN=Certificate Authority,O=YYY -external
false -clone true -clone_p12_file ca.p12 -clone_p12_password
-sd_hostname mmm -sd_admin_port 443 -sd_admin_name admin
-sd_admin_password -clone_start_tls true -clone_uri
https://mmm:443' returned non-zero exit status 255
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
---
/var/log/ipareplica-install.log:
---
[...]
Error in DomainPanel(): updateStatus value is null
ERROR: ConfigureCA: DomainPanel() failure
ERROR: unable to create CA
###
2015-01-06T13:36:25Z DEBUG stderr=
2015-01-06T13:36:25Z CRITICAL failed to configure ca instance Command
'/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname
2015-01-06T13:36:25Z INFO File
/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py, line
614, in run_script
return_value = main_function()
File /usr/sbin/ipa-replica-install, line 476, in main
(CA, cs) = cainstance.install_replica_ca(config)
File
/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py, line
1626, in install_replica_ca
subject_base=config.subject_base)
File
/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py, line
626, in configure_instance
self.start_creation(runtime=210)
File /usr/lib/python2.6/site-packages/ipaserver/install/service.py,
line 358, in start_creation
method()
File
/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py, line
888, in __configure_instance
raise RuntimeError('Configuration of CA failed')
2015-01-06T13:36:25Z INFO The ipa-replica-install command failed,
exception: RuntimeError: Configuration of CA failed
---
Omitting --setup-ca lets me successfully install a working replica
server.
The problem appears to be my installation (since the other one works) -
however: Both (intended) replica servers are nearly identical (operating
system version, installed packages, etc.).
My understanding is that a replica without a CA is not a 100%-clone of a
IPA master, right? What are the downsides of having a replica without a
CA?
Mit freundlichen Gruessen/With best regards,
--Daniel.
--
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] autofs - nfsnobody
Hi Gerardo, On Tue, 3 Feb 2015, Gerardo Cuppari wrote: Hello there again! I'm bothering you again because I am having some problems with autofs/NFS and IPA. All files created from a regular user (enrolled client) gets the nfsnobody user and group. Folder gets auto mounted. just a guess: I had this symptom with a non-Redhat, self-configured client. It turned out, that it was required to set --- Domain = my.domain.de --- in /etc/idmapd.conf Maybe worth a try. Thanks in advance! Here is what I did to configure it at server (server.estudio) and client (pc01.estudio): SERVER = ipa service-add nfs/server.estudio ipa-getkeytab -s server.estudio -p nfs/server.estudio -k /etc/krb5.keytab ipa-client-automount mkdir /export chmod 777 /export echo /export *(rw,sync,sec=sys:krb5:krb5i:krb5p) /etc/exports reboot ** CLIENT ipa-getkeytab -s server.estudio -p host/server.estudio@ESTUDIO -k /etc/krb5.keytab ipa-client-automount reboot echo aaa /export/aaa [user@pc01 /]$ ls -la /export total 12 drwxrwxrwx. 2 root root 4096 feb 3 13:36 . dr-xr-xr-x. 21 root root 4096 feb 3 13:36 .. -rw-rw-r--. 1 nfsnobody nfsnobody4 feb 3 13:36 aaa Mit freundlichen Gruessen/With best regards, --Daniel. -- 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 question
Hi, On Tue, 27 Jan 2015, Csaba Kollar wrote: I’ve installed ipa-server-3.0.0-42.el6.centos.x86_64 on CentOS 6.6 servers. Configured first as a master. Configured second as a replica. Everything went smooth, no errors. If I create a user on the master, it automatically shows up on the replica. BUT If I create a user on the replica, I cannot see on the master the created user. (or if i delete a user on replica which was created on master, it stays on the masters) I’ve tried to force-sync the master without luck: [root@centosm ~]# ipa-replica-manage force-sync --from centosr.macp.sh [...] sounds like the problem I had recently, please check https://fedorahosted.org/freeipa/ticket/4807 for details. Mit freundlichen Gruessen/With best regards, --Daniel. -- 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] Having trouble running FreeIPA with SRV records on externally managed DNS
Rob, On Mon, 19 Jan 2015, rob.har...@stfc.ac.uk wrote: I have successfully set up a test FreeIPA server and run it for a while, but the time has come to move towards a production service. I am currently running ipa-server version 3.0.0-25 on Scientific Linux 6.4 (if you don't know it, Scientific Linux is basically a rebuild of RedHat, much like CentOS). Yes, I know this is an older FreeIPA, but I am going through the path of least resistance given our site's current standard configuration. On our site there is a central DNS service and it is unlikely we will be allowed to run our own DNS service (other than as a slave/cacheing NS). I have been trying to set up SRV records for the FreeIPA server by providing the autogenerated zone file to our DNS manager, who has incorporated the configuration. When we deployed these changes, I used dig to confirm that SRV queries were giving appropriate responses, which they appear to be. I then tried setting up a client using ipa-client-install and got an error: Failed to verify that freeipa01.munged.domain is an IPA Server. This may mean that the remote server is not up or is not reachable due to network or firewall settings. The install worked on a client before deploying the SRV records, using manual specification of the server. I disabled iptables on the server to eliminate potential problems there, and got the same result. If we disable the SRV records, I am able to do the manual set-up again. So it looks like the problem is at the DNS end of things, so maybe our zone configuration is missing something. The zone config we currently have in place is as follows (we changed hostnames in the sample file to fqdns for this attempt, but the same symptoms came from bare hostnames)... ; ldap servers _ldap._tcp.my.domain. IN SRV 0 100 389 freeipa01.my.domain. ; ; kerberos realm _kerberos.my.domain. IN TXT my.domain. this looks odd to me, our central DNS TXT record zone entry looks like --- _kerberos 86400 IN TXTMY.DOMAIN --- where MY.DOMAIN is my Kerberos realm (usually the domain name in capital letters). If you do a --- dig +short -t TXT _kerberos.my.domain --- it should answer --- MY.DOMAIN --- ; ; kerberos servers _kerberos._tcp.my.domain. IN SRV 0 100 88 freeipa01.my.domain. _kerberos._udp.my.domain. IN SRV 0 100 88 freeipa01.my.domain. _kerberos-master._tcp.my.domain. IN SRV 0 100 88 freeipa01.my.domain. _kerberos-master._udp.my.domain. IN SRV 0 100 88 freeipa01.my.domain. _kpasswd._tcp.my.domain. IN SRV 0 100 464 freeipa01.my.domain. _kpasswd._udp.my.domain. IN SRV 0 100 464 freeipa01.my.domain. ; ; ntp server _ntp._udp.my.domain. IN SRV 0 100 123 freeipa01.my.domain. ...So that is where I am. I was hoping that someone could give me a pointer or two as to how I might debug this problem and actually get service discovery working. Mit freundlichen Gruessen/With best regards, --Daniel. -- 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] Replica install fails when using --setup-ca
Hi,
no ideas about this one?
I'm unsure if I did something wrong, but since I installed both systems
the same way, I really don't know, what could be wrong.
One thing that may be related: The working system (the one that doesn't
fail to create a replica with --setup-ca) went productive in April 2014,
the one that fails in September 2014. In between were several updates to
the ipa-server package, including one related to Dogtag (Proxy calls to
/ca/ee/ca/profileSubmit to PKI to enable installation of replicas with
Dogtag 10 PKI (#1083878)). Can this cause errors like the one I observe?
Something else I may want to look into? My installations are pretty much
standard, except that I use an external DNS and have SELinux disabled.
Best regards,
--Daniel.
On Tue, 6 Jan 2015, dbisc...@hrz.uni-kassel.de wrote:
I have two small FreeIPA installations (for two different realms), both
with CentOS 6/FreeIPA 3.0.0-42. After running them both with only one
master server each for a while, I attempted to extend both installations
with one replica each.
Doing a
ipa-replica-install --setup-ca /var/lib/ipa/replica-info-...
worked fine for one of the installations, but failed for the other:
---
[...]
[3/17]: configuring certificate server instance ipa : CRITICAL failed
to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent
ConfigureCA -cs_hostname xxx -cs_port 9445 -client_certdb_dir
/tmp/tmp-YsXvhP -client_certdb_pwd -preop_pin
vJl0m3xc9Oz7b1fIgttD -domain_name IPA -admin_user admin -admin_email
root@localhost -admin_password -agent_name ipa-ca-agent
-agent_key_size 2048 -agent_key_type rsa -agent_cert_subject
CN=ipa-ca-agent,O=YYY -ldap_host xxx -ldap_port 7389 -bind_dn
cn=Directory Manager -bind_password -base_dn o=ipaca -db_name
ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA
-save_p12 true -backup_pwd -subsystem_name pki-cad -token_name
internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=YYY
-ca_subsystem_cert_subject_name CN=CA Subsystem,O=YYY
-ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=YYY
-ca_server_cert_subject_name CN=xxx,O=YYY
-ca_audit_signing_cert_subject_name CN=CA Audit,O=YYY
-ca_sign_cert_subject_name CN=Certificate Authority,O=YYY -external
false -clone true -clone_p12_file ca.p12 -clone_p12_password
-sd_hostname mmm -sd_admin_port 443 -sd_admin_name admin
-sd_admin_password -clone_start_tls true -clone_uri
https://mmm:443' returned non-zero exit status 255
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
---
/var/log/ipareplica-install.log:
---
[...]
Error in DomainPanel(): updateStatus value is null
ERROR: ConfigureCA: DomainPanel() failure
ERROR: unable to create CA
###
2015-01-06T13:36:25Z DEBUG stderr=
2015-01-06T13:36:25Z CRITICAL failed to configure ca instance Command
'/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname
2015-01-06T13:36:25Z INFO File
/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py, line
614, in run_script
return_value = main_function()
File /usr/sbin/ipa-replica-install, line 476, in main
(CA, cs) = cainstance.install_replica_ca(config)
File /usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py,
line 1626, in install_replica_ca
subject_base=config.subject_base)
File /usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py,
line 626, in configure_instance
self.start_creation(runtime=210)
File /usr/lib/python2.6/site-packages/ipaserver/install/service.py, line
358, in start_creation
method()
File /usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py,
line 888, in __configure_instance
raise RuntimeError('Configuration of CA failed')
2015-01-06T13:36:25Z INFO The ipa-replica-install command failed, exception:
RuntimeError: Configuration of CA failed
---
Omitting --setup-ca lets me successfully install a working replica
server.
The problem appears to be my installation (since the other one works) -
however: Both (intended) replica servers are nearly identical (operating
system version, installed packages, etc.).
My understanding is that a replica without a CA is not a 100%-clone of a
IPA master, right? What are the downsides of having a replica without a
CA?
--
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
[Freeipa-users] Replica install fails when using --setup-ca
Hi,
I have two small FreeIPA installations (for two different realms), both
with CentOS 6/FreeIPA 3.0.0-42. After running them both with only one
master server each for a while, I attempted to extend both installations
with one replica each.
Doing a
ipa-replica-install --setup-ca /var/lib/ipa/replica-info-...
worked fine for one of the installations, but failed for the other:
---
[...]
[3/17]: configuring certificate server instance ipa : CRITICAL failed to
configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent
ConfigureCA -cs_hostname xxx -cs_port 9445 -client_certdb_dir
/tmp/tmp-YsXvhP -client_certdb_pwd -preop_pin
vJl0m3xc9Oz7b1fIgttD -domain_name IPA -admin_user admin -admin_email
root@localhost -admin_password -agent_name ipa-ca-agent
-agent_key_size 2048 -agent_key_type rsa -agent_cert_subject
CN=ipa-ca-agent,O=YYY -ldap_host xxx -ldap_port 7389 -bind_dn cn=Directory
Manager -bind_password -base_dn o=ipaca -db_name ipaca -key_size
2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd
-subsystem_name pki-cad -token_name internal
-ca_subsystem_cert_subject_name CN=CA Subsystem,O=YYY
-ca_subsystem_cert_subject_name CN=CA Subsystem,O=YYY
-ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=YYY
-ca_server_cert_subject_name CN=xxx,O=YYY
-ca_audit_signing_cert_subject_name CN=CA Audit,O=YYY
-ca_sign_cert_subject_name CN=Certificate Authority,O=YYY -external false
-clone true -clone_p12_file ca.p12 -clone_p12_password
-sd_hostname mmm -sd_admin_port 443 -sd_admin_name admin
-sd_admin_password -clone_start_tls true -clone_uri
https://mmm:443' returned non-zero exit status 255
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
---
/var/log/ipareplica-install.log:
---
[...]
Error in DomainPanel(): updateStatus value is null
ERROR: ConfigureCA: DomainPanel() failure
ERROR: unable to create CA
###
2015-01-06T13:36:25Z DEBUG stderr=
2015-01-06T13:36:25Z CRITICAL failed to configure ca instance Command
'/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname
2015-01-06T13:36:25Z INFO File
/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py, line
614, in run_script
return_value = main_function()
File /usr/sbin/ipa-replica-install, line 476, in main
(CA, cs) = cainstance.install_replica_ca(config)
File /usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py,
line 1626, in install_replica_ca
subject_base=config.subject_base)
File /usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py,
line 626, in configure_instance
self.start_creation(runtime=210)
File /usr/lib/python2.6/site-packages/ipaserver/install/service.py,
line 358, in start_creation
method()
File /usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py,
line 888, in __configure_instance
raise RuntimeError('Configuration of CA failed')
2015-01-06T13:36:25Z INFO The ipa-replica-install command failed,
exception: RuntimeError: Configuration of CA failed
---
Omitting --setup-ca lets me successfully install a working replica
server.
The problem appears to be my installation (since the other one works) -
however: Both (intended) replica servers are nearly identical (operating
system version, installed packages, etc.).
My understanding is that a replica without a CA is not a 100%-clone of a
IPA master, right? What are the downsides of having a replica without a
CA?
Thank you for looking into this,
--Daniel.
--
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] 3.0.0-42 Replication issue after Centos6.5-6.6 upgrade
Hi, On Mon, 15 Dec 2014, dbisc...@hrz.uni-kassel.de wrote: On Tue, 25 Nov 2014, Rich Megginson wrote: On 11/25/2014 12:32 PM, dbisc...@hrz.uni-kassel.de wrote: with the help of Thierry and Rich I managed to debug the running ns-slapd on Server1 (see below). The failing attempt of decoding the SASL data returns a not very fruitful -1 (SASL_FAIL, generic failure). Any ideas? Short summary: Server1 = running IPA server Server2 = intended IPA replica Both machines run the exact same, up-to-date version of CentOS 6.6. However: I had to run ipa-replica-install _without_ the option --setup-ca (didn't work, installation failed with some obscure Perl error), so there's no ns-slapd instance running for PKI-IPA. May this be related? [...] At this point, it's going to take more than a trivial amount of high latency back-and-forth on the mailling lists. I think we have probably run out of log levels for you to try. Please open a ticket against IPA. While this may turn out to be a bug in 389, at the moment it is only reproducible in your IPA environment. [...] I've opened Ticket #4807 https://fedorahosted.org/freeipa/ticket/4807 on this issue. problem resolved, increasing nsslapd-sasl-max-buffer-size to 2MB did it. I administer 2 very small installations, with ~20 users and ~10 hosts each. If this happens with installations like mine, the default for new installations should probably be raised in the next 3.0.0 update package. I've closed the ticket. Thank you for your support. Mit freundlichen Gruessen/With best regards, --Daniel. -- 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] 3.0.0-42 Replication issue after Centos6.5-6.6 upgrade
Hi, On Tue, 25 Nov 2014, Rich Megginson wrote: On 11/25/2014 12:32 PM, dbisc...@hrz.uni-kassel.de wrote: with the help of Thierry and Rich I managed to debug the running ns-slapd on Server1 (see below). The failing attempt of decoding the SASL data returns a not very fruitful -1 (SASL_FAIL, generic failure). Any ideas? Short summary: Server1 = running IPA server Server2 = intended IPA replica Both machines run the exact same, up-to-date version of CentOS 6.6. However: I had to run ipa-replica-install _without_ the option --setup-ca (didn't work, installation failed with some obscure Perl error), so there's no ns-slapd instance running for PKI-IPA. May this be related? [...] At this point, it's going to take more than a trivial amount of high latency back-and-forth on the mailling lists. I think we have probably run out of log levels for you to try. Please open a ticket against IPA. While this may turn out to be a bug in 389, at the moment it is only reproducible in your IPA environment. [...] I've opened Ticket #4807 https://fedorahosted.org/freeipa/ticket/4807 on this issue. [...] Mit freundlichen Gruessen/With best regards, --Daniel. -- 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] Replica Setup Issue
Hi Matt, I ran into this a couple of months ago. I ended up creating the replica without --setup-ca which first appeared to work, but then it turned out that replication is (at least for me) broken, cf. Ticket #4807 (https://fedorahosted.org/freeipa/ticket/4807). On Fri, 12 Dec 2014, Matt Chesler wrote: 1. Create replica ipa-1 from old-ipa-1 2. Followed procedure documented at http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master to make ipa-1 the node responsible for CRL generation and CA renewal 3. Prepare ipa-2 to be a replica by running 'ipa-replica-prepare ipa-2.example.com' on ipa-1 and copying over the resulting gpg 4. Ran ipa-replica-install on ipa-2 and received the following output/failure: === [root@ipa-2 ~]# ipa-replica-install --setup-ca /var/lib/ipa/replica-info-ipa-2.example.com.gpg [...] [3/17]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ipa-2.example.com -cs_port 9445 -client_certdb_dir /tmp/tmp-ATedaS -client_certdb_pwd -preop_pin SAW89xQS4ICFy5zYWv0m -domain_name IPA -admin_user admin -admin_email root@localhost -admin_password -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=EXAMPLE.COM -ldap_host ipa-2.example.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM -ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=EXAMPLE.COM -ca_server_cert_subject_name CN=ipa-2.example.com,O=EXAMPLE.COM -ca_audit_signing_cert_subject_name CN=CA Audit,O=EXAMPLE.COM -ca_sign_cert_subject_name CN=Certificate Authority,O=EXAMPLE.COM -external false -clone true -clone_p12_file ca.p12 -clone_p12_password -sd_hostname ipa-1.example.com -sd_admin_port 443 -sd_admin_name admin -sd_admin_password -clone_start_tls true -clone_uri https://ipa-1.example.com:443' returned non-zero exit status 255 Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Configuration of CA failed === [...] Mit freundlichen Gruessen/With best regards, --Daniel. -- 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] 3.0.0-42 Replication issue after Centos6.5-6.6 upgrade
Hi, with the help of Thierry and Rich I managed to debug the running ns-slapd on Server1 (see below). The failing attempt of decoding the SASL data returns a not very fruitful -1 (SASL_FAIL, generic failure). Any ideas? Short summary: Server1 = running IPA server Server2 = intended IPA replica Both machines run the exact same, up-to-date version of CentOS 6.6. However: I had to run ipa-replica-install _without_ the option --setup-ca (didn't work, installation failed with some obscure Perl error), so there's no ns-slapd instance running for PKI-IPA. May this be related? On Fri, 21 Nov 2014, Rich Megginson wrote: On 11/21/2014 04:51 AM, thierry bordaz wrote: On 11/21/2014 10:59 AM, dbisc...@hrz.uni-kassel.de wrote: On Thu, 20 Nov 2014, thierry bordaz wrote: On 11/20/2014 12:03 PM, dbisc...@hrz.uni-kassel.de wrote: On Thu, 20 Nov 2014, thierry bordaz wrote: Server1 successfully replicated to Server2, but Server2 fails to replicated to Server1. The replication Server2-Server1 is done with kerberos authentication. Server1 receives the replication session, successfully identify the replication manager, start to receives replication extop but suddenly closes the connection. [19/Nov/2014:14:21:39 +0100] conn=2980 fd=78 slot=78 connection from xxx to yyy [19/Nov/2014:14:21:39 +0100] conn=2980 op=0 BIND dn= method=sasl version=3 mech=GSSAPI [19/Nov/2014:14:21:39 +0100] conn=2980 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [19/Nov/2014:14:21:39 +0100] conn=2980 op=1 BIND dn= method=sasl version=3 mech=GSSAPI [19/Nov/2014:14:21:39 +0100] conn=2980 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [19/Nov/2014:14:21:39 +0100] conn=2980 op=2 BIND dn= method=sasl version=3 mech=GSSAPI [19/Nov/2014:14:21:39 +0100] conn=2980 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn=krbprincipalname=xxx [19/Nov/2014:14:21:39 +0100] conn=2980 op=3 SRCH base= scope=0 filter=(objectClass=*) attrs=supportedControl supportedExtension [19/Nov/2014:14:21:39 +0100] conn=2980 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [19/Nov/2014:14:21:39 +0100] conn=2980 op=4 SRCH base= scope=0 filter=(objectClass=*) attrs=supportedControl supportedExtension [19/Nov/2014:14:21:39 +0100] conn=2980 op=4 RESULT err=0 tag=101 nentries=1 etime=0 [19/Nov/2014:14:21:39 +0100] conn=2980 op=5 EXT oid=2.16.840.1.113730.3.5.12 name=replication-multimaster-extop [19/Nov/2014:14:21:39 +0100] conn=2980 op=5 RESULT err=0 tag=120 nentries=0 etime=0 [19/Nov/2014:14:21:39 +0100] conn=2980 op=6 SRCH base=cn=schema scope=0 filter=(objectClass=*) attrs=nsSchemaCSN [19/Nov/2014:14:21:39 +0100] conn=2980 op=6 RESULT err=0 tag=101 nentries=1 etime=0 [19/Nov/2014:14:21:39 +0100] conn=2980 op=-1 fd=78 closed - I/O function error. The reason of this closure is logged in server1 error log. sasl_decode fails to decode a received PDU. [19/Nov/2014:14:21:39 +0100] - sasl_io_recv failed to decode packet for connection 2980 I do not know why it fails but I wonder if the received PDU is not larger than the maximum configured value. The attribute nsslapd-maxsasliosize is set to 2Mb by default. Would it be possible to increase its value (5Mb) to see if it has an impact [...] I set nsslapd-maxsasliosize to 6164480 on both machines, but the problem remains. The sasl-decode fails but the exact returned value is not logged. With standard version we may need to attach a debugger and then set a conditional breakpoint in sasl-decode just after conn-oparams.decode that will fire if result !=0. Now this can change the dynamic and possibly prevent the problem to occur again. The other option is to use an instrumented version to log this value. If I understand the mechanism correctly, Server1 needs to have debug versions of the relevant packages (probably 389-ds-base and cyrus-sasl) installed in order to track down the problem. Unfortunately, my Server1 is in production use - if I break it, my colleagues will grab forks and torches and be after me. A short downtime would be ok, though. Is there something else I could do? Sure I do not want to trigger so much trouble ;-) I think my email was not clear. To go further we would need to know the exact reason why sasl_decode fails. I see two options: * Prepare a debug version, that would report in the error logs the returned valud of sasl_decode (when it fails). Except downtime to install the debug version, it has no impact in production. * Do a debug session (gdb) on Server1. The debug session will install a breakpoint at a specific place, let the server run, catch the sasl_decode failure and note the return code, exit from debugger. When the problem occurs, it happens regularly (each 5 seconds) so we should not have to wait long. That means that debugging Server1 should disturb production for 5 to 10 min. A detailed procedure to do the
Re: [Freeipa-users] 3.0.0-42 Replication issue after Centos6.5-6.6 upgrade
Hi, On Thu, 20 Nov 2014, thierry bordaz wrote: Server1 successfully replicated to Server2, but Server2 fails to replicated to Server1. The replication Server2-Server1 is done with kerberos authentication. Server1 receives the replication session, successfully identify the replication manager, start to receives replication extop but suddenly closes the connection. [19/Nov/2014:14:21:39 +0100] conn=2980 fd=78 slot=78 connection from xxx to yyy [19/Nov/2014:14:21:39 +0100] conn=2980 op=0 BIND dn= method=sasl version=3 mech=GSSAPI [19/Nov/2014:14:21:39 +0100] conn=2980 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [19/Nov/2014:14:21:39 +0100] conn=2980 op=1 BIND dn= method=sasl version=3 mech=GSSAPI [19/Nov/2014:14:21:39 +0100] conn=2980 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [19/Nov/2014:14:21:39 +0100] conn=2980 op=2 BIND dn= method=sasl version=3 mech=GSSAPI [19/Nov/2014:14:21:39 +0100] conn=2980 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn=krbprincipalname=xxx [19/Nov/2014:14:21:39 +0100] conn=2980 op=3 SRCH base= scope=0 filter=(objectClass=*) attrs=supportedControl supportedExtension [19/Nov/2014:14:21:39 +0100] conn=2980 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [19/Nov/2014:14:21:39 +0100] conn=2980 op=4 SRCH base= scope=0 filter=(objectClass=*) attrs=supportedControl supportedExtension [19/Nov/2014:14:21:39 +0100] conn=2980 op=4 RESULT err=0 tag=101 nentries=1 etime=0 [19/Nov/2014:14:21:39 +0100] conn=2980 op=5 EXT oid=2.16.840.1.113730.3.5.12 name=replication-multimaster-extop [19/Nov/2014:14:21:39 +0100] conn=2980 op=5 RESULT err=0 tag=120 nentries=0 etime=0 [19/Nov/2014:14:21:39 +0100] conn=2980 op=6 SRCH base=cn=schema scope=0 filter=(objectClass=*) attrs=nsSchemaCSN [19/Nov/2014:14:21:39 +0100] conn=2980 op=6 RESULT err=0 tag=101 nentries=1 etime=0 [19/Nov/2014:14:21:39 +0100] conn=2980 op=-1 fd=78 closed - I/O function error. The reason of this closure is logged in server1 error log. sasl_decode fails to decode a received PDU. [19/Nov/2014:14:21:39 +0100] - sasl_io_recv failed to decode packet for connection 2980 I do not know why it fails but I wonder if the received PDU is not larger than the maximum configured value. The attribute nsslapd-maxsasliosize is set to 2Mb by default. Would it be possible to increase its value (5Mb) to see if it has an impact [...] I set nsslapd-maxsasliosize to 6164480 on both machines, but the problem remains. Mit freundlichen Gruessen/With best regards, --Daniel. -- 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] 3.0.0-42 Replication issue after Centos6.5-6.6 upgrade
Hi, On Fri, 7 Nov 2014, Dmitri Pal wrote: On 11/07/2014 01:24 AM, Will Sheldon wrote: On November 6, 2014 at 10:07:54 PM, Dmitri Pal (d...@redhat.com mailto:d...@redhat.com) wrote: On 11/07/2014 12:18 AM, Will Sheldon wrote: On the whole we are loving FreeIPA, Many thanks and much respect to all involved, we’ve had a great 12-18 months hassle free use out of it - it is a fantastically stable trouble free solution… however now we’ve run into a small issue we (as mere mortals) are finding it hard to resolve :-/ We upgraded our ipa servers (3.0.0-42) to Centos 6.6. everything seems to go well, but one server is behaving oddly. It’s likely not an IPA issue, it also reset it’s hostname somehow after the upgrade (it’s an image in an openstack environment) If anyone has any pointers as to how to debug I’d be hugely appreciative :) Two servers, server1.domain.com and server2.domain.com Server1 can’t push data to server2, there are updates and new records on server1 that do not exist on server2. from the logs on server1: [07/Nov/2014:01:33:42 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Warning: unable to send endReplication extended operation (Can't contact LDAP server) [07/Nov/2014:01:33:47 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Replication bind with GSSAPI auth resumed [07/Nov/2014:01:33:48 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Warning: unable to replicate schema: rc=2 [07/Nov/2014:01:33:48 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later. Try to see a) Server 1 properly resolves server 2 b) You can connect from server 1 to server 2 using ldapsearch c) your firewall has proper ports open d) dirserver on server 2 is actually running All seems working: [root@server1 ~]# ldapsearch -x -H ldap://server2.domain.com -s base -b '' namingContexts Can you try kinit admin and then use kerberos GSSAPI to connect, i.e. -Y switch? is this resolved? I observe it on my systems, too. Exact same symptoms. ldapsearch with -Y GSSAPI works. Did you find anything in the server2 logs? On my server2, I see sasl_io_recv failed to decode packet for connection #. Could there be something wrong with default buffer sizes as described in https://bugzilla.redhat.com/show_bug.cgi?id=953653 I have nsslapd-sasl-max-buffer-size: 65536 on both machines, but my database is rather small: ~30 users, 10 hosts and services. # extended LDIF # # LDAPv3 # base with scope baseObject # filter: (objectclass=*) # requesting: namingContexts # # dn: namingContexts: dc=domain,dc=com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@server1 ~]# And: [root@server2 ~]# /etc/init.d/dirsrv status dirsrv DOMAIN-COM (pid 1009) is running... dirsrv PKI-IPA (pid 1083) is running... [root@server2 ~]# Check logs on server 2 to see whether it actually sees an attempt to connect, I suspect not, so it is most likely a DNS/FW issue or dir server is not running on 2. and the servers: [root@server1 ~]# ipa-replica-manage list -v `hostname` Directory Manager password: server2.domain.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update started last update ended: 2014-11-07 01:35:58+00:00 [root@server1 ~]# [root@server2 ~]# ipa-replica-manage list -v `hostname` Directory Manager password: server1.domain.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-11-07 01:35:43+00:00 [root@server2 ~]# Mit freundlichen Gruessen/With best regards, --Daniel. -- 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] User auth for Samba 3 file server against IPA 3.0.0
Hi, On Sun, 10 Aug 2014, Dmitri Pal wrote: On 07/21/2014 10:15 AM, dbisc...@hrz.uni-kassel.de wrote: On Wed, 16 Jul 2014, Dmitri Pal wrote: On 07/16/2014 07:16 AM, dbisc...@hrz.uni-kassel.de wrote: I have IPA running on a CentOS 6 server. This server also acts as NFS- and Samba server. My Linux clients (openSUSE 13.1) work fine (NFS, automount, user auth for ssh and display manager). Since I also have some Windows users, I want them to be able to mount their homes via Samba using their IPA password. Just that, no AD or other fancy stuff. Support of Windows users is still where it was. Code might have changed so the solution might not apply any more cleanly. Our general vision is that windows users belong to Windows and have to be either in AD or in Samba4. As soon as Samba 4 supports cross forest trusts we will make it supported. Then we will be able to support cases like you describe. Also right now Samba FS as a member of IPA domain does not work well. It should work better with SSSD 1.12.1 and IPA 4.1 when we make sure that all parts are in place but that would still have some problems when one has to come from windows client as there is no SSSD equivalent for windows clients. Bottom line: no, there is no better info, sorry. Bummer. Just to make sure: I don't want my Windows users to be able to log on to their systems using IPA auth, they all have local accounts. I just want them to be able to manually mount their home shares. Sorry for a delayed response, I am slowly catching up on these threads. Mounting a share requires authentication with the account that Samba FS server knows about. Samba FS server until now could have been joined to AD only. Samba 4 DC can be used as an alternative of AD. But in both cases Samba FS yet can't be a member of the IPA domain. We are working on it. So once it is done you might be able to manually mount shares using the accounts managed by IPA. It is a question of couple months really so may be you can wait for this functionality to emerge and try it? will that feature (Samba shares w/ IPA accounts) be available for IPA 3.0 as in RHEL/CentOS6 or for IPA4 only? Waiting another couple of months would be perfectly ok for me, if I could then just update the IPA package and do some additional configuration to make it work. I'd happily take part in testing the feature in advance, too. Mit freundlichen Gruessen/With best regards, --Daniel. -- 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] User auth for Samba 3 file server against IPA 3.0.0
Dmitri, thanks for your answer. On Wed, 16 Jul 2014, Dmitri Pal wrote: On 07/16/2014 07:16 AM, dbisc...@hrz.uni-kassel.de wrote: I have IPA running on a CentOS 6 server. This server also acts as NFS- and Samba server. My Linux clients (openSUSE 13.1) work fine (NFS, automount, user auth for ssh and display manager). Since I also have some Windows users, I want them to be able to mount their homes via Samba using their IPA password. Just that, no AD or other fancy stuff. Support of Windows users is still where it was. Code might have changed so the solution might not apply any more cleanly. Our general vision is that windows users belong to Windows and have to be either in AD or in Samba4. As soon as Samba 4 supports cross forest trusts we will make it supported. Then we will be able to support cases like you describe. Also right now Samba FS as a member of IPA domain does not work well. It should work better with SSSD 1.12.1 and IPA 4.1 when we make sure that all parts are in place but that would still have some problems when one has to come from windows client as there is no SSSD equivalent for windows clients. Bottom line: no, there is no better info, sorry. Bummer. Just to make sure: I don't want my Windows users to be able to log on to their systems using IPA auth, they all have local accounts. I just want them to be able to manually mount their home shares. Since I'm still more or less testing stuff, I wonder where to go from here. Before biting the bullet having separate Samba accounts: Would it help to switch to Samba 4? This post https://www.redhat.com/archives/freeipa-users/2013-April/msg00248.html suggests that it's possible. Somebody out there did it successfully? [1] http://techslaves.org/2011/08/24/freeipa-and-samba-3-integration/ Mit freundlichen Gruessen/With best regards, --Daniel. -- 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
[Freeipa-users] User auth for Samba 3 file server against IPA 3.0.0
Hi, this has been discussed on this list and elsewhere [1], but I'm still a little puzzled: I have IPA running on a CentOS 6 server. This server also acts as NFS- and Samba server. My Linux clients (openSUSE 13.1) work fine (NFS, automount, user auth for ssh and display manager). Since I also have some Windows users, I want them to be able to mount their homes via Samba using their IPA password. Just that, no AD or other fancy stuff. I read the instructions at [1], which appear to suit my case but at least the group.js UI patch is outdated. Is there a more recent howto to follow? Is patching the source at all still necessary? Will doing so break the opportunity to install a replica (a step that I have planned but not yet accomplished)? Thanks for your help. [1] http://techslaves.org/2011/08/24/freeipa-and-samba-3-integration/ Mit freundlichen Gruessen/With best regards, --Daniel. -- 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
