Re: [Freeipa-users] Mount cifs share using kerberos
2015-01-11 16:33 GMT+01:00 Jakub Hrozek jhro...@redhat.com: On Sun, Jan 11, 2015 at 11:00:16AM +0100, John Obaterspok wrote: 2015-01-10 13:32 GMT+01:00 Gianluca Cecchi gianluca.cec...@gmail.com: To get the whole root environment you have to run su - root did you try with it? ahh... that works fine Gianluca! Final question, if I have a file on the share like: [john@ipaserver mountpoint]$ ll test.txt -rwxr-. 1 root admins 12 11 jan 10.42 test.txt Should I be able to access it if I aquire an admin ticket? Currently I get Permission denied [john@ipaserver mountpoint]$ id uid=143444(john) gid=143444(john) grupper=143444(john) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [john@ipaserver mountpoint]$ getfacl test.txt # file: test.txt # owner: root # group: admins user::rwx group::r-- other::--- [john@ipaserver mountpoint]$ id admin uid=143440(admin) gid=143440(admins) groups=143440(admins) [john@ipaserver mountpoint]$ klist Ticket cache: KEYRING:persistent:143444:krb_ccache_MVjxTqf Default principal: ad...@my.lan Valid starting Expires Service principal 2015-01-11 10:43:52 2015-01-12 10:43:50 krbtgt/my@my.lan [john@ipaserver mountpoint]$ cat test.txt cat: test.txt: Permission denied Looks like your account needs to be in the 'admins' group in order to access the file. Acquiring the admin ticket doesn't switch the user ID nor add you to the group.. I thought the krb5 mount option would allow ticked based access to the file. Is the purpose of the krb5 mount option just used during mounting of the share? Otherwise I see no difference compared to not using krb5 mount option!? -- john -- 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] freeipa authentication token manipulation error
The sssd version is 1.11.6 The password does not get changed, whatever password gets generated by ipa user-mod --random stays valid even after attempting the change. krb5_child.log does not have any contents. Thanks, Rakesh On Sun, Jan 11, 2015 at 9:01 PM, Jakub Hrozek jhro...@redhat.com wrote: On Sun, Jan 11, 2015 at 02:31:26PM +0530, Rakesh Rajasekharan wrote: Hi, I am having some issues with freeipa. Whenever I change the password for any user, He is not able to change the password. and he gets error authentication token manipualtion error Changing password for user hq-testuser. Current Password: New password: Retype new password: passwd: Authentication token manipulation error I was able to get this running on another environment not sure whats went wrong here. I have migrated my exisitng users from openldap . Thanks, Rakesh What is the sssd version? Is the password changed despite the error (you can test with kinit and either the new or the old password) ? Increasing sssd log verbosity and checking krb5_child.log might help, too. -- 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 -- 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] Group Policy-like features in FreeIPA
On 11.1.2015 22:16, Dale Macartney wrote: Morning folks I am currently working on a little pet project which I think some would find useful. I would like to introduce some group policy like functionality into a FreeIPA domain. For example: In an environment running FreeIPA Server with Fedora or RHEL based workstations, I would like to be able to introduce a few extra features which initially may be pushed via a login script (maybe even configure a dbus session as well, who knows?). My intentions here would be to be able to apply host specific policies as well as have the option for user specific policies which would be applied when the user logs in. Practically speaking, adding an attribute to LDAP to specify a login script file name is easy enough, however actually fetching this is where I am hoping for a bit of brain storming. My thoughts would be the local user would fetch the name of the login script via ldap, and then perhaps fetch the file from a shared resource on the FreeIPA masters in order to be executed locally. LDAP is obviously replicated, however to my knowledge, there is no file synchronization between masters. I am thinking something similar to the MS equivalent of the SYSVOL data that replicates between MS Domain Controllers. One option would be to store all data within LDAP, however I've seen many scenarios where admins store CD ISO's in replicated domain data, so I am not certain this would be the best option. With this replicated data folder, I would be able to store centrally managed scripts which would be used for hosts or users, and then configure the default user template on each workstation (/etc/skel/) to add the login script file name which would be fetched from the users LDAP attributes. Real world usability for what I am thinking of is a way to manage users who can have their corporate email mailbox configured on login, automatically setting the users session to point to an internal SSO enabled proxy server or perhaps any other number of things which an admin may wish to achieve without the need to manually do the work themselves. Has anyone undertaken a similar scenario in their environments or would perhaps have any suggestions on how to manage the centrally accessible file stores? Personally I'm not sure if FreeIPA is the right tool for configuration management. IMHO you would end up re-implementing Puppet/Ansible/other configuration management system. IMHO FreeIPA is the right place to manage policy-kit policies because these are basically access control rules but I would not go much further. (BTW newer versions of policy-kit can express policy as normal javascript code which in theory could call/communicate with a wrapper around LDAP/SSSD.) -- Petr^2 Spacek -- 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] Mount cifs share using kerberos
On Mon, 12 Jan 2015, John Obaterspok wrote: 2015-01-11 16:33 GMT+01:00 Jakub Hrozek jhro...@redhat.com: On Sun, Jan 11, 2015 at 11:00:16AM +0100, John Obaterspok wrote: 2015-01-10 13:32 GMT+01:00 Gianluca Cecchi gianluca.cec...@gmail.com: To get the whole root environment you have to run su - root did you try with it? ahh... that works fine Gianluca! Final question, if I have a file on the share like: [john@ipaserver mountpoint]$ ll test.txt -rwxr-. 1 root admins 12 11 jan 10.42 test.txt Should I be able to access it if I aquire an admin ticket? Currently I get Permission denied [john@ipaserver mountpoint]$ id uid=143444(john) gid=143444(john) grupper=143444(john) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [john@ipaserver mountpoint]$ getfacl test.txt # file: test.txt # owner: root # group: admins user::rwx group::r-- other::--- [john@ipaserver mountpoint]$ id admin uid=143440(admin) gid=143440(admins) groups=143440(admins) [john@ipaserver mountpoint]$ klist Ticket cache: KEYRING:persistent:143444:krb_ccache_MVjxTqf Default principal: ad...@my.lan Valid starting Expires Service principal 2015-01-11 10:43:52 2015-01-12 10:43:50 krbtgt/my@my.lan [john@ipaserver mountpoint]$ cat test.txt cat: test.txt: Permission denied Looks like your account needs to be in the 'admins' group in order to access the file. Acquiring the admin ticket doesn't switch the user ID nor add you to the group.. I thought the krb5 mount option would allow ticked based access to the file. Is the purpose of the krb5 mount option just used during mounting of the share? Otherwise I see no difference compared to not using krb5 mount option!? Its purpose is authentication. After you have been successfully recognized by the server, both client and server need to map your identity while authorizing your access to actual files. In CIFS there are two types of access control which are applied at the same time: - ACLs per file or directory - POSIX access control based on uid/gid of a process that accesses the file or directory Client-side checks in cifs.ko can be switched off by noperm option. In this case server side will be doing actual access enforcement, using the uid/gid mapped on the server side (based on the Kerberos principal), unless CIFS Unix Extensions were negotiated between cifs.ko and the server. In the latter case client will pass uid/gid of a client to the server and server will do the actual check using them instead of discovering them based on the authentication token. In case where there is a common identity store in use with Kerberos, it is often better to use cifs.ko option multiuser which will imply noperm and server will be doing all the checks. -- / Alexander Bokovoy -- 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] freeipa authentication token manipulation error
On (12/01/15 14:12), Rakesh Rajasekharan wrote: The sssd version is 1.11.6 The password does not get changed, whatever password gets generated by ipa user-mod --random stays valid even after attempting the change. krb5_child.log does not have any contents. The logging in sssd is dibsabled by default. You need to increase level of verbosity. Put debug_level = 7 into domain section and restart sssd. It is also possible to change debug level on the fly with comand line utility sss_debuglevel (part of pacakge sssd-tools) LS -- 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] Group Policy-like features in FreeIPA
On 01/12/2015 06:52 AM, Martin Kosek wrote: On 01/12/2015 10:04 AM, Petr Spacek wrote: On 11.1.2015 22:16, Dale Macartney wrote: Morning folks I am currently working on a little pet project which I think some would find useful. I would like to introduce some group policy like functionality into a FreeIPA domain. For example: In an environment running FreeIPA Server with Fedora or RHEL based workstations, I would like to be able to introduce a few extra features which initially may be pushed via a login script (maybe even configure a dbus session as well, who knows?). My intentions here would be to be able to apply host specific policies as well as have the option for user specific policies which would be applied when the user logs in. Practically speaking, adding an attribute to LDAP to specify a login script file name is easy enough, however actually fetching this is where I am hoping for a bit of brain storming. My thoughts would be the local user would fetch the name of the login script via ldap, and then perhaps fetch the file from a shared resource on the FreeIPA masters in order to be executed locally. LDAP is obviously replicated, however to my knowledge, there is no file synchronization between masters. I am thinking something similar to the MS equivalent of the SYSVOL data that replicates between MS Domain Controllers. One option would be to store all data within LDAP, however I've seen many scenarios where admins store CD ISO's in replicated domain data, so I am not certain this would be the best option. With this replicated data folder, I would be able to store centrally managed scripts which would be used for hosts or users, and then configure the default user template on each workstation (/etc/skel/) to add the login script file name which would be fetched from the users LDAP attributes. Real world usability for what I am thinking of is a way to manage users who can have their corporate email mailbox configured on login, automatically setting the users session to point to an internal SSO enabled proxy server or perhaps any other number of things which an admin may wish to achieve without the need to manually do the work themselves. Has anyone undertaken a similar scenario in their environments or would perhaps have any suggestions on how to manage the centrally accessible file stores? Personally I'm not sure if FreeIPA is the right tool for configuration management. IMHO you would end up re-implementing Puppet/Ansible/other configuration management system. Maybe. Though note that this not the first attempt to add a file storage to FreeIPA. It is currently tracked in https://fedorahosted.org/freeipa/ticket/1225, free for takers. I at least added a link to this proposal when the RFE is revisited. Martin I would say there are two parts: - The scripts that need to be delivered and run - Information which scripts to run and parameters of the script Storing scripts in IPA is IMO a bad idea. However IPA is a reasonable place for storing information related to a script invocation. Scripts can be delivered with Puppet/Chef/Salt/Ansible or just live on a mount point. IPA can be a good place to store this mount point and identify the script and arguments to run on login from that mount point. 2c. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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
Re: [Freeipa-users] freeipa authentication token manipulation error
On 01/11/2015 04:01 AM, Rakesh Rajasekharan wrote: Hi, I am having some issues with freeipa. Whenever I change the password for any user, He is not able to change the password. and he gets error authentication token manipualtion error Changing password for user hq-testuser. Current Password: New password: Retype new password: passwd: Authentication token manipulation error I was able to get this running on another environment not sure whats went wrong here. I have migrated my exisitng users from openldap . Does it happen for all users or only users that you migrated? Can you create a new user and set a password for him? If it does not work I suspect either something is wrong with either krb5.conf or global password policy on the server. If it works for new users but not for migrated ones then compare the entries of such users using ldap command and see what is different. Thanks, Rakesh -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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] Group Policy-like features in FreeIPA
On 01/12/2015 10:04 AM, Petr Spacek wrote: On 11.1.2015 22:16, Dale Macartney wrote: Morning folks I am currently working on a little pet project which I think some would find useful. I would like to introduce some group policy like functionality into a FreeIPA domain. For example: In an environment running FreeIPA Server with Fedora or RHEL based workstations, I would like to be able to introduce a few extra features which initially may be pushed via a login script (maybe even configure a dbus session as well, who knows?). My intentions here would be to be able to apply host specific policies as well as have the option for user specific policies which would be applied when the user logs in. Practically speaking, adding an attribute to LDAP to specify a login script file name is easy enough, however actually fetching this is where I am hoping for a bit of brain storming. My thoughts would be the local user would fetch the name of the login script via ldap, and then perhaps fetch the file from a shared resource on the FreeIPA masters in order to be executed locally. LDAP is obviously replicated, however to my knowledge, there is no file synchronization between masters. I am thinking something similar to the MS equivalent of the SYSVOL data that replicates between MS Domain Controllers. One option would be to store all data within LDAP, however I've seen many scenarios where admins store CD ISO's in replicated domain data, so I am not certain this would be the best option. With this replicated data folder, I would be able to store centrally managed scripts which would be used for hosts or users, and then configure the default user template on each workstation (/etc/skel/) to add the login script file name which would be fetched from the users LDAP attributes. Real world usability for what I am thinking of is a way to manage users who can have their corporate email mailbox configured on login, automatically setting the users session to point to an internal SSO enabled proxy server or perhaps any other number of things which an admin may wish to achieve without the need to manually do the work themselves. Has anyone undertaken a similar scenario in their environments or would perhaps have any suggestions on how to manage the centrally accessible file stores? Personally I'm not sure if FreeIPA is the right tool for configuration management. IMHO you would end up re-implementing Puppet/Ansible/other configuration management system. Maybe. Though note that this not the first attempt to add a file storage to FreeIPA. It is currently tracked in https://fedorahosted.org/freeipa/ticket/1225, free for takers. I at least added a link to this proposal when the RFE is revisited. Martin -- 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] freeipa authentication token manipulation error
This is what I get now a=in the krb5_child.log after setting the debug_level Mon Jan 12 09:51:14 2015) [[sssd[krb5_child[21709 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_71061_XX] keytab: [/etc/krb5.keytab] (Mon Jan 12 09:51:14 2015) [[sssd[krb5_child[21709 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Mon Jan 12 09:51:14 2015) [[sssd[krb5_child[21709 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Mon Jan 12 09:51:14 2015) [[sssd[krb5_child[21709 [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Mon Jan 12 09:51:14 2015) [[sssd[krb5_child[21709 [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/ qa-dummy-int.test@test.com)] (Mon Jan 12 09:51:14 2015) [[sssd[krb5_child[21709 [match_principal] (0x1000): Principal matched to the sample (host/ qa-dummy-int.test@test.com). (Mon Jan 12 09:51:14 2015) [[sssd[krb5_child[21709 [check_fast_ccache] (0x0200): FAST TGT is still valid. (Mon Jan 12 09:51:14 2015) [[sssd[krb5_child[21709 [main] (0x0400): Will perform password change (Mon Jan 12 09:51:14 2015) [[sssd[krb5_child[21709 [changepw_child] (0x1000): Password change operation (Mon Jan 12 09:51:14 2015) [[sssd[krb5_child[21709 [changepw_child] (0x0400): Attempting kinit for realm [TEST.COM] On Mon, Jan 12, 2015 at 2:31 PM, Lukas Slebodnik lsleb...@redhat.com wrote: On (12/01/15 14:12), Rakesh Rajasekharan wrote: The sssd version is 1.11.6 The password does not get changed, whatever password gets generated by ipa user-mod --random stays valid even after attempting the change. krb5_child.log does not have any contents. The logging in sssd is dibsabled by default. You need to increase level of verbosity. Put debug_level = 7 into domain section and restart sssd. It is also possible to change debug level on the fly with comand line utility sss_debuglevel (part of pacakge sssd-tools) LS -- 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] freeipa authentication token manipulation error
under /var/log/secure.. have this error passwd: pam_sss(passwd:chauthtok): Password change failed for user hq-testuser: 22 (Authentication token lock busy) On Mon, Jan 12, 2015 at 3:25 PM, Rakesh Rajasekharan rakesh.rajasekha...@gmail.com wrote: This is what I get now a=in the krb5_child.log after setting the debug_level Mon Jan 12 09:51:14 2015) [[sssd[krb5_child[21709 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_71061_XX] keytab: [/etc/krb5.keytab] (Mon Jan 12 09:51:14 2015) [[sssd[krb5_child[21709 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Mon Jan 12 09:51:14 2015) [[sssd[krb5_child[21709 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Mon Jan 12 09:51:14 2015) [[sssd[krb5_child[21709 [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Mon Jan 12 09:51:14 2015) [[sssd[krb5_child[21709 [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/ qa-dummy-int.test@test.com)] (Mon Jan 12 09:51:14 2015) [[sssd[krb5_child[21709 [match_principal] (0x1000): Principal matched to the sample (host/ qa-dummy-int.test@test.com). (Mon Jan 12 09:51:14 2015) [[sssd[krb5_child[21709 [check_fast_ccache] (0x0200): FAST TGT is still valid. (Mon Jan 12 09:51:14 2015) [[sssd[krb5_child[21709 [main] (0x0400): Will perform password change (Mon Jan 12 09:51:14 2015) [[sssd[krb5_child[21709 [changepw_child] (0x1000): Password change operation (Mon Jan 12 09:51:14 2015) [[sssd[krb5_child[21709 [changepw_child] (0x0400): Attempting kinit for realm [TEST.COM] On Mon, Jan 12, 2015 at 2:31 PM, Lukas Slebodnik lsleb...@redhat.com wrote: On (12/01/15 14:12), Rakesh Rajasekharan wrote: The sssd version is 1.11.6 The password does not get changed, whatever password gets generated by ipa user-mod --random stays valid even after attempting the change. krb5_child.log does not have any contents. The logging in sssd is dibsabled by default. You need to increase level of verbosity. Put debug_level = 7 into domain section and restart sssd. It is also possible to change debug level on the fly with comand line utility sss_debuglevel (part of pacakge sssd-tools) LS -- 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] freeipa authentication token manipulation error
On 01/12/2015 12:55 PM, Rakesh Rajasekharan wrote: This is the full log, Jan 12 17:45:15 10-5-68-5 sshd[29753]: pam_sss(sshd:account): User info message: Password expired. Change your password now. Jan 12 17:45:15 10-5-68-5 sshd[29753]: Accepted password for hq-testuser from 10.5.68.184 port 54048 ssh2 Jan 12 17:45:16 10-5-68-5 sshd[29753]: pam_unix(sshd:session): session opened for user hq-testuser by (uid=0) Jan 12 17:45:16 10-5-68-5 passwd: pam_unix(passwd:chauthtok): user hq-testuser does not exist in /etc/passwd Jan 12 17:45:35 10-5-68-5 passwd: pam_unix(passwd:chauthtok): user hq-testuser does not exist in /etc/passwd Jan 12 17:45:41 10-5-68-5 passwd: pam_sss(passwd:chauthtok): Password change failed for user hq-testuser: 22 (Authentication token lock busy) Jan 12 17:45:43 10-5-68-5 sshd[30329]: Received disconnect from 10.5.68.184 http://10.5.68.184: 11: disconnected by user Jan 12 17:45:43 10-5-68-5 sshd[29753]: pam_unix(sshd:session): session closed for user hq-testuser Does it happen for all users or only users that you migrated? Yes it happens for all, I created a new user ( hq-testuser) is a fresh one that I created. I found a workaround for this , users are able to successfully change the password by connecting to the IPA master server. So, its only the ipa clients that have the issue. Does it work for the same user from the client if you reset password on the server, authenticate from the client and then force reset again on the server? Can you add a new client and see whether it works there? Have you tried re-installing the client? Thanks, Rakesh On Mon, Jan 12, 2015 at 10:57 PM, Jakub Hrozek jhro...@redhat.com mailto:jhro...@redhat.com wrote: On Mon, Jan 12, 2015 at 04:01:32PM +0530, Rakesh Rajasekharan wrote: under /var/log/secure.. have this error passwd: pam_sss(passwd:chauthtok): Password change failed for user hq-testuser: 22 (Authentication token lock busy) It looks like the log was trucated, can you post more context? Authentication token lock busy usually means the kadmin servers were offline.. -- 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 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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] Password policy for admin account not working
sipazzo wrote: Good morning, I created a service password policy that prevents password expiration and gave it a priority of 0. I then created a service user group and applied the policy to the group. I added my admin user to this group so their password would not expire. However, it continues to expire anyway. I have other (not built-in) accounts that use this policy successfully so it seems like the priority is not working correctly. I am unable to change the priority on the global_policy. Is my only option to add another policy with the same config as the global policy but a lower priority and assign that to all my users? Password policy for expiration is applied at the time the password is changed/set, not retroactively, so you may just need to reset the password on those accounts. To see what policy will be applied to a give user do: $ ipa pwpolicy-show --user=someuser rob -- 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] I think I trashed my FreeIPA CA - how to recover?
Hi folks, really pleased with the latest versions of FreeIPA. Very robust, quite impressive! In the process of setting it up, I ended up having to move servers a couple of times. The original server is gone, just replicas that installed cleanly with each other. The problem is I didn't realize I was destroying the CA in the process. Maybe because I didn't promote the CA before the original was blown away. This was about three months ago and now I'm having a hard time recovering. I did use the --setup-ca option every time a replica was made, but I can't tell what was salvaged and what was lost. (Maybe the installer could warn about this for the PBKAC types like myself...) I have a fairly large investment in the configuration of the LDAP (domains, hosts and accounts) and need to maintain those somehow. I'm expecting that my certificates will probably have to be started from scratch though. Can anyone offer advice how to proceed? Thanks kindly, Brian -- 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] freeipa authentication token manipulation error
Does it work for the same user from the client if you reset password on the server, authenticate from the client and then force reset again on the server? When I force reset a user, he stil faces the same error token manipulation when tries to login to a client. However, when he tries getting into the server, he now gets prompted for the password change and is successfully able to get through. So, at this point we have a workaround though something seems not right at the clients. Can you add a new client and see whether it works there? Have you tried re-installing the client? Yes, I did try reinstalling but that did not help Sorry, I meant the full krb5_child.log ... This is how I get the logs in krb5_child. when a user tries to authenticate with the random password that I generated, WARNING: Your password has expired. You must change your password now and login again! Changing password for user hq-testuser. Current Password: New password: Retype new password: passwd: Authentication token manipulation erro And on the krb5_child.log, these are the entries (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_71061_XX] keytab: [/etc/krb5.keytab] (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/ qa-dummy-int.test@test.com] (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [match_principal] (0x1000): Principal matched to the sample (host/ qa-dummy-int.test@test.com). (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [check_fast_ccache] (0x0200): FAST TGT is still valid. (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [main] (0x0400): Will perform password change (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [changepw_child] (0x1000): Password change operation (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [changepw_child] (0x0400): Attempting kinit for realm [TEST.COM] This does not go beyond this. however, when i attempt another login , the logs start moving from this point( the time stamp start from 6:54 AM) WARNING: Your password has expired. You must change your password now and login again! Changing password for user hq-testuser. Current Password: New password: Retype new password: passwd: Authentication token manipulation erro now the krb5_child.log adds following lines (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [main] (0x0400): krb5_child started. (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [unpack_buffer] (0x1000): total buffer size: [134]TEST (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [unpack_buffer] (0x0100): cmd [241] uid [71061] gid [71061] validate [true] enterprise principal [false] offline [false] UPN [hq-testu...@test.com] (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_71061_XX] keytab: [/etc/krb5.keytab] (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/ qa-dummy-int.test@test.com] (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [match_principal] (0x1000): Principal matched to the sample (host/ qa-dummy-int.test@test.com). (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [check_fast_ccache] (0x0200): FAST TGT is still valid. (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [main] (0x0400): Will perform online auth (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [tgt_req_child] (0x1000): Attempting to get a TGT (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [get_and_save_tgt] (0x0400): Attempting kinit for realm [TEST.COM] (Tue Jan 13 06:54:53 2015) [[sssd[krb5_child[23514 [get_and_save_tgt] (0x0020): 981: [-1765328361][Password has expired] (Tue Jan 13 06:54:53 2015) [[sssd[krb5_child[23514 [tgt_req_child] (0x1000): Password was expired (Tue Jan 13 06:54:56 2015) [[sssd[krb5_child[23514 [k5c_send_data] (0x0200): Received error code 1432158213 (Tue Jan 13 06:54:56 2015) [[sssd[krb5_child[23514 [main] (0x0400): krb5_child completed successfully
Re: [Freeipa-users] Getfedora.org ssl cert issue
On 12.1.2015 16:31, brendan kearney wrote: Can someone up-channel an issue with getfedora.org? The site changed URLs, and the cert was not amended to include the new URL as a Subject Alternative Name and now cert mismatches are occurring. Please open a ticket on https://fedorahosted.org/fedora-infrastructure/ -- Petr^2 Spacek -- 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] Adding/Editing Users/Groups with the same name
Myles Merrell wrote: I'm trying to add a 'backup' user AND a 'backup' group. At one point in the past a backup group did exist. I have a backup group. I then try to create a new user and get the following error: IPA Error 4024 Unable to create private group. A group 'backup' already exists. I also tried creating the backup user first then the group, and I get: IPA Error 4002 group with name backup already exists How do I create a backup user and backup group, and if not why? You need the noprivate option, e.g. $ ipa group-show backup grab the GID $ ipa user-add --noprivate --first=Backup --last=User --gid=gid backup rob -- 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] Group Policy-like features in FreeIPA
From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dale Macartney Sent: Sunday, January 11, 2015 2:16 PM To: freeipa-users@redhat.com Subject: [Freeipa-users] Group Policy-like features in FreeIPA Morning folks I am currently working on a little pet project which I think some would find useful. I would like to introduce some group policy like functionality into a FreeIPA domain. For example: In an environment running FreeIPA Server with Fedora or RHEL based workstations, I would like to be able to introduce a few extra features which initially may be pushed via a login script (maybe even configure a dbus session as well, who knows?). My intentions here would be to be able to apply host specific policies as well as have the option for user specific policies which would be applied when the user logs in. Practically speaking, adding an attribute to LDAP to specify a login script file name is easy enough, however actually fetching this is where I am hoping for a bit of brain storming. My thoughts would be the local user would fetch the name of the login script via ldap, and then perhaps fetch the file from a shared resource on the FreeIPA masters in order to be executed locally. LDAP is obviously replicated, however to my knowledge, there is no file synchronization between masters. I am thinking something similar to the MS equivalent of the SYSVOL data that replicates between MS Domain Controllers. One option would be to store all data within LDAP, however I've seen many scenarios where admins store CD ISO's in replicated domain data, so I am not certain this would be the best option. With this replicated data folder, I would be able to store centrally managed scripts which would be used for hosts or users, and then configure the default user template on each workstation (/etc/skel/) to add the login script file name which would be fetched from the users LDAP attributes. Real world usability for what I am thinking of is a way to manage users who can have their corporate email mailbox configured on login, automatically setting the users session to point to an internal SSO enabled proxy server or perhaps any other number of things which an admin may wish to achieve without the need to manually do the work themselves. Has anyone undertaken a similar scenario in their environments or would perhaps have any suggestions on how to manage the centrally accessible file stores? Many thanks Specifically, I haven’t fully implemented what you are asking but obviously parts and pieces yes. One of the best features of Linux and all of its various toolsets is that one are quite so overarching and the objectives are more focused. String them together and you have a working tool set. As a system administrator, you learn to pipe grep output to awk or sed or cut etc. SYSVOL = NFS and if that doesn’t do it for you, check out Unison. I guess one of the temptations of FreeIPA is to try to make it exactly like active directory. The FreeIPA developers are already doing an amazing job without a ton of manpower. Craig -- 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] Getfedora.org ssl cert issue
Can someone up-channel an issue with getfedora.org? The site changed URLs, and the cert was not amended to include the new URL as a Subject Alternative Name and now cert mismatches are occurring. -- 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] Adding/Editing Users/Groups with the same name
I'm trying to add a 'backup' user AND a 'backup' group. At one point in the past a backup group did exist. I have a backup group. I then try to create a new user and get the following error:IPA Error 4024Unable to create private group. A group 'backup' already exists. I also tried creating the backup user first then the group, and I get:IPA Error 4002group with name backup already exists How do I create a backup user and backup group, and if not why? thanks.myles. -- 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] Group Policy-like features in FreeIPA
OpenAFS? On Jan 12, 2015 11:04 AM, Craig White cwh...@skytouchtechnology.com wrote: *From:* freeipa-users-boun...@redhat.com [mailto: freeipa-users-boun...@redhat.com] *On Behalf Of *Dale Macartney *Sent:* Sunday, January 11, 2015 2:16 PM *To:* freeipa-users@redhat.com *Subject:* [Freeipa-users] Group Policy-like features in FreeIPA Morning folks I am currently working on a little pet project which I think some would find useful. I would like to introduce some group policy like functionality into a FreeIPA domain. For example: In an environment running FreeIPA Server with Fedora or RHEL based workstations, I would like to be able to introduce a few extra features which initially may be pushed via a login script (maybe even configure a dbus session as well, who knows?). My intentions here would be to be able to apply host specific policies as well as have the option for user specific policies which would be applied when the user logs in. Practically speaking, adding an attribute to LDAP to specify a login script file name is easy enough, however actually fetching this is where I am hoping for a bit of brain storming. My thoughts would be the local user would fetch the name of the login script via ldap, and then perhaps fetch the file from a shared resource on the FreeIPA masters in order to be executed locally. LDAP is obviously replicated, however to my knowledge, there is no file synchronization between masters. I am thinking something similar to the MS equivalent of the SYSVOL data that replicates between MS Domain Controllers. One option would be to store all data within LDAP, however I've seen many scenarios where admins store CD ISO's in replicated domain data, so I am not certain this would be the best option. With this replicated data folder, I would be able to store centrally managed scripts which would be used for hosts or users, and then configure the default user template on each workstation (/etc/skel/) to add the login script file name which would be fetched from the users LDAP attributes. Real world usability for what I am thinking of is a way to manage users who can have their corporate email mailbox configured on login, automatically setting the users session to point to an internal SSO enabled proxy server or perhaps any other number of things which an admin may wish to achieve without the need to manually do the work themselves. Has anyone undertaken a similar scenario in their environments or would perhaps have any suggestions on how to manage the centrally accessible file stores? Many thanks Specifically, I haven’t fully implemented what you are asking but obviously parts and pieces yes. One of the best features of Linux and all of its various toolsets is that one are quite so overarching and the objectives are more focused. String them together and you have a working tool set. As a system administrator, you learn to pipe grep output to awk or sed or cut etc. SYSVOL ó NFS and if that doesn’t do it for you, check out Unison. I guess one of the temptations of FreeIPA is to try to make it exactly like active directory. The FreeIPA developers are already doing an amazing job without a ton of manpower. Craig -- 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 -- 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] freeipa authentication token manipulation error
This is the full log, Jan 12 17:45:15 10-5-68-5 sshd[29753]: pam_sss(sshd:account): User info message: Password expired. Change your password now. Jan 12 17:45:15 10-5-68-5 sshd[29753]: Accepted password for hq-testuser from 10.5.68.184 port 54048 ssh2 Jan 12 17:45:16 10-5-68-5 sshd[29753]: pam_unix(sshd:session): session opened for user hq-testuser by (uid=0) Jan 12 17:45:16 10-5-68-5 passwd: pam_unix(passwd:chauthtok): user hq-testuser does not exist in /etc/passwd Jan 12 17:45:35 10-5-68-5 passwd: pam_unix(passwd:chauthtok): user hq-testuser does not exist in /etc/passwd Jan 12 17:45:41 10-5-68-5 passwd: pam_sss(passwd:chauthtok): Password change failed for user hq-testuser: 22 (Authentication token lock busy) Jan 12 17:45:43 10-5-68-5 sshd[30329]: Received disconnect from 10.5.68.184: 11: disconnected by user Jan 12 17:45:43 10-5-68-5 sshd[29753]: pam_unix(sshd:session): session closed for user hq-testuser Does it happen for all users or only users that you migrated? Yes it happens for all, I created a new user ( hq-testuser) is a fresh one that I created. I found a workaround for this , users are able to successfully change the password by connecting to the IPA master server. So, its only the ipa clients that have the issue. Thanks, Rakesh On Mon, Jan 12, 2015 at 10:57 PM, Jakub Hrozek jhro...@redhat.com wrote: On Mon, Jan 12, 2015 at 04:01:32PM +0530, Rakesh Rajasekharan wrote: under /var/log/secure.. have this error passwd: pam_sss(passwd:chauthtok): Password change failed for user hq-testuser: 22 (Authentication token lock busy) It looks like the log was trucated, can you post more context? Authentication token lock busy usually means the kadmin servers were offline.. -- 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 -- 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] freeipa authentication token manipulation error
On Mon, Jan 12, 2015 at 11:25:16PM +0530, Rakesh Rajasekharan wrote: This is the full log, Sorry, I meant the full krb5_child.log ... -- 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] freeipa authentication token manipulation error
On Mon, Jan 12, 2015 at 04:01:32PM +0530, Rakesh Rajasekharan wrote: under /var/log/secure.. have this error passwd: pam_sss(passwd:chauthtok): Password change failed for user hq-testuser: 22 (Authentication token lock busy) It looks like the log was trucated, can you post more context? Authentication token lock busy usually means the kadmin servers were offline.. -- 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] Password policy for admin account not working
Good morning, I created a service password policy that prevents password expiration and gave it a priority of 0. I then created a service user group and applied the policy to the group. I added my admin user to this group so their password would not expire. However, it continues to expire anyway. I have other (not built-in) accounts that use this policy successfully so it seems like the priority is not working correctly. I am unable to change the priority on the global_policy. Is my only option to add another policy with the same config as the global policy but a lower priority and assign that to all my users? -- 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
