[Freeipa-users] Announcing FreeIPA 4.1.3
The FreeIPA team would like to announce FreeIPA v4.1.3 bug fix release! It can be downloaded from http://www.freeipa.org/page/Downloads . Fedora 21 builds are already on their way to updates-testing repository. Builds for Fedora 20 are available in the official COPR repository [https://copr.fedoraproject.org/coprs/mkosek/freeipa/]. == Highlights in 4.1.3 == === Enhancements === * ID Views support user SSH public keys * ID Views support IPA user overrides * OTP token authentication and synchronization windows are configurable * RADIUS server proxy fields added to user page in Web UI === Bug fixes === * Issues fixed in ipa-restore: ** doesn't crash if replica is unreachable ** checks if it isn't a restore on non matching host ** improved validation of input options to disallow invalid combinations ** doesn't fail if run on a system without IPA installed ** creates correct log directories * certificate renewal process is synchronized * migrate-ds: warns user if compat plugin is enabled * PassSync plugin could not update synchronized users due to too strict access control * replication agreements by Replication Administrators could not be removed due to strict access control * anonymous read of a DUA profile was not possible due to strict access control * various upgrade fixes related to DNSSEC == Upgrading == Upgrade instructions are available on upgrade page [http://www.freeipa.org/page/Upgrade]. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 4.1.2 == === Alexander Bokovoy (4) === * Support Samba PASSDB 0.2.0 aka interface version 24 * ipa-cldap: support NETLOGON_NT_VERSION_5EX_WITH_IP properly * ipa-kdb: when processing transitions, hand over unknown ones to KDC * ipa-kdb: reject principals from disabled domains as a KDC policy === David Kupka (5) === * Use singular in help metavars + update man pages. * Always add /etc/hosts record when DNS is being configured. * Remove ipanttrustauthincoming/ipanttrustauthoutgoing from ipa trust-add output. * Abort backup restoration on not matching host. * idviews: Allow setting ssh public key on ipauseroverride-add === Gabe Alford (3) === * Remove dependency on subscription-manager * Typos in ipa-rmkeytab options help and man page * permission-add does not prompt for ipapermright in interactive mode === Jan Cholasta (18) === * Fix automatic CA cert renewal endless loop in dogtag-ipa-ca-renew-agent * Do not renew the IPA CA cert by serial number in dogtag-ipa-ca-renew-agent * Improve validation of --instance and --backend options in ipa-restore * Check subject name encoding in ipa-cacert-manage renew * Refer the user to freeipa.org when something goes wrong in ipa-cacert-manage * Fix ipa-restore on systems without IPA installed * Remove RUV from LDIF files before using them in ipa-restore * Fix CA certificate renewal syslog alert * Do not crash on unknown services in installutils.stopped_service * Restart dogtag when its server certificate is renewed * Make certificate renewal process synchronized * Fix validation of ipa-restore options * Do not assume certmonger is running in httpinstance * Put LDIF files to their original location in ipa-restore * Revert Make all ipatokenTOTP attributes mandatory * Create correct log directories during full restore in ipa-restore * Do not crash when replica is unreachable in ipa-restore * Bump 389-ds-base and pki-ca dependencies for POODLE fixes === Jan Pazdziora (1) === * No explicit zone specification. === Martin Babinsky (11) === * Moved dbus-python dependence to freeipa-python package * ipa-kdb: unexpected error code in 'ipa_kdb_audit_as_req' triggers a message * always get PAC for client principal if AS_REQ is true * ipa-kdb: more robust handling of principal addition/editing * OTP: failed search for the user of last token emits an error message * ipa-pwd-extop: added an informational comment about intentional fallthrough * ipa-uuid: emit a message when unexpected mod type is encountered * OTP: emit a log message when LDAP entry for config record is not found * ipa-client-install: put eol character after the last line of altered config file(s) * migrate-ds: exit with error message if no users/groups to migrate are found * Changing the token owner changes also the manager === Martin Bašti (19) === * Fix zonemgr option encoding detection * Throw zonemgr error message before installation proceeds * Upgrade fix: masking named should be executed only once * Using wget to get status of CA * Show SSHFP record containing space in fingerprint * Fix don't check certificate during getting CA status * Fix: Upgrade forwardzones zones after adding newer replica * Fix zone find during forwardzone upgrade * Fix traceback if zonemgr error contains unicode * DNS tests: separate current forward zone tests * New test cases for Forward_zones *
[Freeipa-users] AD sync via polling?
Hi, is it possible to use winsync to sync stuff from AD without having to create domain trusts, or install some kind of sync services on the AD DC's? For some background, we want to fetch user/group info and authenticate against AD (managed by another department), but we also have a need to have some own users/groups on top of the AD ones. So the initial plan would be something like A1. We join a machine to the AD domain, so we can fetch information from AD via getent or ldapsearch. A2. Scripts are written to fetch data from AD on the machine in (1) above, merge and push this user/group data into freeIPA. These scripts run periodically via cron. Clients are configured roughly per the following: B1. sssd on clients is configured to fetch user/group data from freeIPA. B2. pam_krb5 in client machines is configured to authenticate against AD. B3. pam_ldap (or pam_sss, if its use of kerberos doesn't conflict with the configuration for connecting to AD used by pam_krb5?) in client machines is configured to authenticate against freeIPA, for those users who don't have accounts in AD. Yes, I can see this being a lot simpler if we could get a cross domain trust going on between AD and our freeIPA servers or even just the winsync services running on the DC's, but organizational politics being what they are, this isn't happening. :( So my questions are - Can the freeIPA winsync tool bend to providing A2 above, or do we have to do it ourselves? - As this setups is weird and non-standard, will using freeIPA actually help us here, or would life be easier by just using 389 or openldap directly? In essence, our main usage of freeIPA would be to provide management tools for those users/groups which are not synced from AD. - With the constraints above that we have to live with, is there a better way to accomplish this? - Does the thing in B3 work? I.e. can I have pam_krb5 with config in /etc/krb5.conf for connecting to AD, then pam_sss with sssd.conf using the ipa or krb5 auth provider pointing to our freeIPA server(s). Thanks, -- Janne Blomqvist -- 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] AD sync via polling?
On 02/25/2015 07:44 AM, Janne Blomqvist wrote: Hi, is it possible to use winsync to sync stuff from AD without having to create domain trusts, or install some kind of sync services on the AD DC's? For some background, we want to fetch user/group info and authenticate against AD (managed by another department), but we also have a need to have some own users/groups on top of the AD ones. So the initial plan would be something like A1. We join a machine to the AD domain, so we can fetch information from AD via getent or ldapsearch. A2. Scripts are written to fetch data from AD on the machine in (1) above, merge and push this user/group data into freeIPA. These scripts run periodically via cron. Clients are configured roughly per the following: B1. sssd on clients is configured to fetch user/group data from freeIPA. B2. pam_krb5 in client machines is configured to authenticate against AD. B3. pam_ldap (or pam_sss, if its use of kerberos doesn't conflict with the configuration for connecting to AD used by pam_krb5?) in client machines is configured to authenticate against freeIPA, for those users who don't have accounts in AD. Yes, I can see this being a lot simpler if we could get a cross domain trust going on between AD and our freeIPA servers or even just the winsync services running on the DC's, but organizational politics being what they are, this isn't happening. :( So my questions are - Can the freeIPA winsync tool bend to providing A2 above, or do we have to do it ourselves? - As this setups is weird and non-standard, will using freeIPA actually help us here, or would life be easier by just using 389 or openldap directly? In essence, our main usage of freeIPA would be to provide management tools for those users/groups which are not synced from AD. - With the constraints above that we have to live with, is there a better way to accomplish this? - Does the thing in B3 work? I.e. can I have pam_krb5 with config in /etc/krb5.conf for connecting to AD, then pam_sss with sssd.conf using the ipa or krb5 auth provider pointing to our freeIPA server(s). Thanks, You can use SSSD and define two domains one for AD and one for IPA. You join machine to IPA to at least take advantage of what it provides for objects you manage but use AD as a second domain in SSSD configuration. You do not need to sync anything or use pam_krb5/pam_ldap. So no scripts. You can also decide to join the machine into AD instead but I do not see any benefits from doing it. The only price in this setup is that one of the domains (the second one) would have to use fully qualified user names to log into the system. HTH -- 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] AD sync via polling?
On 02/25/2015 06:48 AM, Dmitri Pal wrote: On 02/25/2015 07:44 AM, Janne Blomqvist wrote: Hi, is it possible to use winsync to sync stuff from AD without having to create domain trusts, or install some kind of sync services on the AD DC's? For some background, we want to fetch user/group info and authenticate against AD (managed by another department), but we also have a need to have some own users/groups on top of the AD ones. So the initial plan would be something like A1. We join a machine to the AD domain, so we can fetch information from AD via getent or ldapsearch. A2. Scripts are written to fetch data from AD on the machine in (1) above, merge and push this user/group data into freeIPA. These scripts run periodically via cron. Clients are configured roughly per the following: B1. sssd on clients is configured to fetch user/group data from freeIPA. B2. pam_krb5 in client machines is configured to authenticate against AD. B3. pam_ldap (or pam_sss, if its use of kerberos doesn't conflict with the configuration for connecting to AD used by pam_krb5?) in client machines is configured to authenticate against freeIPA, for those users who don't have accounts in AD. Yes, I can see this being a lot simpler if we could get a cross domain trust going on between AD and our freeIPA servers or even just the winsync services running on the DC's, but organizational politics being what they are, this isn't happening. :( So my questions are - Can the freeIPA winsync tool bend to providing A2 above, or do we have to do it ourselves? - As this setups is weird and non-standard, will using freeIPA actually help us here, or would life be easier by just using 389 or openldap directly? In essence, our main usage of freeIPA would be to provide management tools for those users/groups which are not synced from AD. - With the constraints above that we have to live with, is there a better way to accomplish this? - Does the thing in B3 work? I.e. can I have pam_krb5 with config in /etc/krb5.conf for connecting to AD, then pam_sss with sssd.conf using the ipa or krb5 auth provider pointing to our freeIPA server(s). Thanks, You can use SSSD and define two domains one for AD and one for IPA. You join machine to IPA to at least take advantage of what it provides for objects you manage but use AD as a second domain in SSSD configuration. You do not need to sync anything or use pam_krb5/pam_ldap. So no scripts. You can also decide to join the machine into AD instead but I do not see any benefits from doing it. The only price in this setup is that one of the domains (the second one) would have to use fully qualified user names to log into the system. +1 If however you still want to do something with scripts and the Windows AD DirSync control with polling, see https://github.com/richm/scripts/blob/master/dirsyncctrl.py HTH -- 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] Web UI plugins or other extensions
All, We're running ipa-server-3.0.0-42/389-ds-base-1.2.11.15-48 on CentOS 6.5. We've set up synching between our IPA and AD and that seems to be working. What we'd like to do now is allow admins when they're creating users in IPA to be able to set those users up for synching to AD with the web UI without having to drop to the command line or edit LDAP directly. As you know, in order to synch from IPA-AD, you need to add the ntuser objectclass and the ntUserDomainId and ntUserCreateNewAccount attributes. However, those attributes/class are not in the web UI by defauly and from what I can see, our version of ipa-server/DS does not have support for web UI plugins. Is that true? Is there any way to be able to set a user to be synched via the web UI? Thanks, Hugh -- 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] Web UI plugins or other extensions
On 02/25/2015 09:12 AM, Hugh wrote: All, We're running ipa-server-3.0.0-42/389-ds-base-1.2.11.15-48 on CentOS 6.5. We've set up synching between our IPA and AD and that seems to be working. What we'd like to do now is allow admins when they're creating users in IPA to be able to set those users up for synching to AD with the web UI without having to drop to the command line or edit LDAP directly. As you know, in order to synch from IPA-AD, you need to add the ntuser objectclass and the ntUserDomainId and ntUserCreateNewAccount attributes. However, those attributes/class are not in the web UI by defauly and from what I can see, our version of ipa-server/DS does not have support for web UI plugins. Is that true? Is there any way to be able to set a user to be synched via the web UI? Thanks, Hugh Hello Hugh, it could be done in 3.0 by direct manipulation of /usr/share/ipa/ui/user.js Doing that is ugly and breaks on rpm upgrades. IIUC, the goal would be to simulate CLI (API)call: $ ipa user-mod bbar --addattr='objectclass=ntuser' --setattr='ntUserDomainId=foo'--setattr='ntUserDomainId=True' Adding ntUserDomainId and ntUserDomainId is easy - it's just one declaration in the list of fields. But adding the objectclass isn't, Current pattern is that the object classes(which are not added by default) are added in ipalib backend plugin if attribute is present in the mod list for the first time for the object. I would discourage to do that in Web UI. But in theory it can be done. One has to add multivalued field named objectclass and then he can add new ones and delete others. But this is bad UX. Better would be to add the objecclass attr on demand on update but it requires direct modification of update code which is more difficult (don't know it from top of my head). HTH -- Petr Vobornik -- 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] ipa-getcert list fails to report correctly - RESOLVED
On 2/25/2015 6:35 PM, Martin Kosek wrote: yum -y remove pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util pki-native-tools ipa-server-selinux ipa-server ipa-client ipa-admintools ipa-python ipa-pki-ca-theme ipa-pki-common-theme 389-ds-base 389-ds-base-libs userdel pkisrv userdel pkiuser This should not be needed at all, AFAIK. This may not be related to this problem, but sometimes reinstalling the packages is necessary to resolve installation problem. For example: https://fedorahosted.org/freeipa/ticket/4591 In this ticket reinstalling 389-ds-base will recreate the missing folder. -- Endi S. Dewata -- 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] Forward first not working
Hi Martin, The zone name is the following for both servers. Zone name: 1.10.in-addr.arpa. I am using zone forwarders. With forward first enabled though it should try and return an answer from the local DNS, it clearly does not though. The only time I receive the local record is when forwarding is disabled. Thanks, Shaun [cid:1F369212-0E28-4C3C-8955-33CDA7C2FAB4@blackducksoftware.com] Shaun Martin IT\OPS Manager Black Duck Software O: +1.781.425.4336 Black Duck Softwarehttp://www.blackducksoftware.com/ | OpenHUBhttps://www.openhub.net/ | OSDelivershttp://osdelivers.blackducksoftware.com/ | OSS Logisticshttps://www.blackducksoftware.com/oss-logistics [cid:CC23E6F1-CA96-4E59-978B-D0D9EDE0F2DB@blackducksoftware.com] http://twitter.com/black_duck_sw [cid:AC8F793C-9870-4ECB-B844-3337F98BA51F@blackducksoftware.com] https://www.linkedin.com/company/black-duck-software [cid:AB6B7F6B-C85C-4E52-8B42-9C9A5EB9D0D1@blackducksoftware.com] https://www.facebook.com/BlackDuckSoftware [cid:931AE271-12EC-458A-BB1F-7455AD35B154@blackducksoftware.com] https://plus.google.com/+Blackducksoftware/ [cid:8EB9FA0C-F1E0-4E32-9E58-0D6A646A5625@blackducksoftware.com] http://www.slideshare.net/blackducksoftware [cid:1A0AC858-0DCC-44B4-B3D0-8BB35E291B02@blackducksoftware.com] JP Morgan Chase Co. Hall of Innovation Inductee https://www.youtube.com/user/BlackDuckSoftware https://www.youtube.com/user/BlackDuckSoftware On Feb 25, 2015, at 12:42 PM, Martin Basti mba...@redhat.commailto:mba...@redhat.com wrote: On 25/02/15 17:59, Shaun Martin wrote: Hi, I am having an issue with the forward first not appear to be working. I have two separate IPA servers that server separate realms. I have for the reverse zone configured forwarders to point to the other realms IPA server. All versions are identical on the IPA servers. I have included details on version and tests that show this is not working. $ yum list installed |grep bind-dyndb-ldap bind-dyndb-ldap.x86_64 3.5-4.el7 @base $ yum list installed |grep ipa ipa-admintools.x86_64 3.3.3-28.0.1.el7.centos.3 @updates ipa-client.x86_64 3.3.3-28.0.1.el7.centos.3 @updates ipa-python.x86_64 3.3.3-28.0.1.el7.centos.3 @updates ipa-server.x86_64 3.3.3-28.0.1.el7.centos.3 @updates libipa_hbac.x86_64 1.11.2-68.el7_0.6 @updates libipa_hbac-python.x86_64 1.11.2-68.el7_0.6 @updates python-iniparse.noarch 0.4-9.el7 @anaconda sssd-ipa.x86_64 BELOW IS WITH FORWARDING DISABLED. It cannot find 10.1.0.9 but can find 10.1.20.9. This is expected as this server only has the 10.1.20.9 record. $ nslookup server 10.1.20.9 Default server: 10.1.20.9 Address: 10.1.20.9#53 10.1.20.9 Server: 10.1.20.9 Address: 10.1.20.9#53 9.20.1.10.in-addr.arpa name = prd-ops-ipa01.uzb.local. 10.1.0.9 Server: 10.1.20.9 Address: 10.1.20.9#53 ** server can't find 9.0.1.10.in-addr.arpa.: NXDOMAIN BELOW IS WITH FORWARDING ENABLED. It cannot find 10.1.20.9 but can find 10.1.0.9. This is expected as the forwarding server only has the 10.1.0.9 record. 10.1.20.9 Server: 10.1.20.9 Address: 10.1.20.9#53 ** server can't find 9.20.1.10.in-addr.arpa.: NXDOMAIN 10.1.0.9 Server: 10.1.20.9 Address: 10.1.20.9#53 Non-authoritative answer: 9.0.1.10.in-addr.arpa name = ops-ipa01.bbf.local. Authoritative answers can be found from: 1.10.in-addr.arpa nameserver = ops-ipa01.bbf.local. BELOW IS WITH FORWARD FIRST ENABLED. It cannot find 10.1.20.9 but can find 10.1.0.9. This is un-expected as the local zone has the 10.1.20.9 and the forward server has the 10.1.0.9 so we should be getting both. 10.1.20.9 Server: 10.1.20.9 Address: 10.1.20.9#53 ** server can't find 9.20.1.10.in-addr.arpa.: NXDOMAIN 10.1.0.9 Server: 10.1.20.9 Address: 10.1.20.9#53 Non-authoritative answer: 9.0.1.10.in-addr.arpa name = ops-ipa01.bbf.local. Authoritative answers can be found from: 1.10.in-addr.arpa nameserver = ops-ipa01.bbf.local. ops-ipa01.bbf.local internet address = 10.1.0.9 Any help is greatly appreciated. Thanks, Shaun Mail Attachment.png Shaun Martin IT\OPS Manager Black Duck Software O: +1.781.425.4336 Black Duck Softwarehttp://www.blackducksoftware.com/ | OpenHUBhttps://www.openhub.net/ | OSDelivershttp://osdelivers.blackducksoftware.com/ | OSS Logisticshttps://www.blackducksoftware.com/oss-logistics Mail Attachment.png http://twitter.com/black_duck_sw Mail Attachment.png https://www.linkedin.com/company/black-duck-software Mail Attachment.png https://www.facebook.com/BlackDuckSoftware Mail Attachment.png https://plus.google.com/+Blackducksoftware/ Mail Attachment.png http://www.slideshare.net/blackducksoftware Mail Attachment.png JP Morgan Chase Co. Hall of Innovation Inductee https://www.youtube.com/user/BlackDuckSoftware Hello, we need more
[Freeipa-users] Forward first not working
Hi, I am having an issue with the forward first not appear to be working. I have two separate IPA servers that server separate realms. I have for the reverse zone configured forwarders to point to the other realms IPA server. All versions are identical on the IPA servers. I have included details on version and tests that show this is not working. $ yum list installed |grep bind-dyndb-ldap bind-dyndb-ldap.x86_64 3.5-4.el7 @base $ yum list installed |grep ipa ipa-admintools.x86_64 3.3.3-28.0.1.el7.centos.3 @updates ipa-client.x86_64 3.3.3-28.0.1.el7.centos.3 @updates ipa-python.x86_64 3.3.3-28.0.1.el7.centos.3 @updates ipa-server.x86_64 3.3.3-28.0.1.el7.centos.3 @updates libipa_hbac.x86_64 1.11.2-68.el7_0.6 @updates libipa_hbac-python.x86_64 1.11.2-68.el7_0.6 @updates python-iniparse.noarch 0.4-9.el7 @anaconda sssd-ipa.x86_64 BELOW IS WITH FORWARDING DISABLED. It cannot find 10.1.0.9 but can find 10.1.20.9. This is expected as this server only has the 10.1.20.9 record. $ nslookup server 10.1.20.9 Default server: 10.1.20.9 Address: 10.1.20.9#53 10.1.20.9 Server: 10.1.20.9 Address: 10.1.20.9#53 9.20.1.10.in-addr.arpa name = prd-ops-ipa01.uzb.local. 10.1.0.9 Server: 10.1.20.9 Address: 10.1.20.9#53 ** server can't find 9.0.1.10.in-addr.arpa.: NXDOMAIN BELOW IS WITH FORWARDING ENABLED. It cannot find 10.1.20.9 but can find 10.1.0.9. This is expected as the forwarding server only has the 10.1.0.9 record. 10.1.20.9 Server: 10.1.20.9 Address: 10.1.20.9#53 ** server can't find 9.20.1.10.in-addr.arpa.: NXDOMAIN 10.1.0.9 Server: 10.1.20.9 Address: 10.1.20.9#53 Non-authoritative answer: 9.0.1.10.in-addr.arpa name = ops-ipa01.bbf.local. Authoritative answers can be found from: 1.10.in-addr.arpa nameserver = ops-ipa01.bbf.local. BELOW IS WITH FORWARD FIRST ENABLED. It cannot find 10.1.20.9 but can find 10.1.0.9. This is un-expected as the local zone has the 10.1.20.9 and the forward server has the 10.1.0.9 so we should be getting both. 10.1.20.9 Server: 10.1.20.9 Address: 10.1.20.9#53 ** server can't find 9.20.1.10.in-addr.arpa.: NXDOMAIN 10.1.0.9 Server: 10.1.20.9 Address: 10.1.20.9#53 Non-authoritative answer: 9.0.1.10.in-addr.arpa name = ops-ipa01.bbf.local. Authoritative answers can be found from: 1.10.in-addr.arpa nameserver = ops-ipa01.bbf.local. ops-ipa01.bbf.local internet address = 10.1.0.9 Any help is greatly appreciated. Thanks, Shaun [cid:1F369212-0E28-4C3C-8955-33CDA7C2FAB4@blackducksoftware.com] Shaun Martin IT\OPS Manager Black Duck Software O: +1.781.425.4336 Black Duck Softwarehttp://www.blackducksoftware.com/ | OpenHUBhttps://www.openhub.net/ | OSDelivershttp://osdelivers.blackducksoftware.com/ | OSS Logisticshttps://www.blackducksoftware.com/oss-logistics [cid:CC23E6F1-CA96-4E59-978B-D0D9EDE0F2DB@blackducksoftware.com] http://twitter.com/black_duck_sw [cid:AC8F793C-9870-4ECB-B844-3337F98BA51F@blackducksoftware.com] https://www.linkedin.com/company/black-duck-software [cid:AB6B7F6B-C85C-4E52-8B42-9C9A5EB9D0D1@blackducksoftware.com] https://www.facebook.com/BlackDuckSoftware [cid:931AE271-12EC-458A-BB1F-7455AD35B154@blackducksoftware.com] https://plus.google.com/+Blackducksoftware/ [cid:8EB9FA0C-F1E0-4E32-9E58-0D6A646A5625@blackducksoftware.com] http://www.slideshare.net/blackducksoftware [cid:1A0AC858-0DCC-44B4-B3D0-8BB35E291B02@blackducksoftware.com] JP Morgan Chase Co. Hall of Innovation Inductee https://www.youtube.com/user/BlackDuckSoftware https://www.youtube.com/user/BlackDuckSoftware -- 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] Web UI plugins or other extensions
On 02/25/2015 09:53 AM, Petr Vobornik wrote: On 02/25/2015 09:12 AM, Hugh wrote: All, We're running ipa-server-3.0.0-42/389-ds-base-1.2.11.15-48 on CentOS 6.5. We've set up synching between our IPA and AD and that seems to be working. What we'd like to do now is allow admins when they're creating users in IPA to be able to set those users up for synching to AD with the web UI without having to drop to the command line or edit LDAP directly. As you know, in order to synch from IPA-AD, you need to add the ntuser objectclass and the ntUserDomainId and ntUserCreateNewAccount attributes. However, those attributes/class are not in the web UI by defauly and from what I can see, our version of ipa-server/DS does not have support for web UI plugins. Is that true? Is there any way to be able to set a user to be synched via the web UI? Thanks, Hugh Hello Hugh, it could be done in 3.0 by direct manipulation of /usr/share/ipa/ui/user.js Doing that is ugly and breaks on rpm upgrades. IIUC, the goal would be to simulate CLI (API)call: $ ipa user-mod bbar --addattr='objectclass=ntuser' --setattr='ntUserDomainId=foo'--setattr='ntUserDomainId=True' Adding ntUserDomainId and ntUserDomainId is easy - it's just one declaration in the list of fields. But adding the objectclass isn't, Current pattern is that the object classes(which are not added by default) are added in ipalib backend plugin if attribute is present in the mod list for the first time for the object. I would discourage to do that in Web UI. But in theory it can be done. One has to add multivalued field named objectclass and then he can add new ones and delete others. But this is bad UX. Better would be to add the objecclass attr on demand on update but it requires direct modification of update code which is more difficult (don't know it from top of my head). HTH But let us step back and ask the question why do you need to create the users you sync manually first? The users in a specific OU will be synced anyways without you manually creating them in IPA. So this is unclear why the whole thing is actually needed. -- 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] Forward first not working
On 25/02/15 17:59, Shaun Martin wrote: Hi, I am having an issue with the forward first not appear to be working. I have two separate IPA servers that server separate realms. I have for the reverse zone configured forwarders to point to the other realms IPA server. All versions are identical on the IPA servers. I have included details on version and tests that show this is not working. $ yum list installed |grep bind-dyndb-ldap bind-dyndb-ldap.x86_64 3.5-4.el7 @base $ yum list installed |grep ipa ipa-admintools.x86_64 3.3.3-28.0.1.el7.centos.3 @updates ipa-client.x86_64 3.3.3-28.0.1.el7.centos.3 @updates ipa-python.x86_64 3.3.3-28.0.1.el7.centos.3 @updates ipa-server.x86_64 3.3.3-28.0.1.el7.centos.3 @updates libipa_hbac.x86_64 1.11.2-68.el7_0.6 @updates libipa_hbac-python.x86_64 1.11.2-68.el7_0.6 @updates python-iniparse.noarch 0.4-9.el7 @anaconda sssd-ipa.x86_64 *BELOW IS WITH FORWARDING DISABLED*. It cannot find 10.1.0.9 but can find 10.1.20.9. This is expected as this server only has the 10.1.20.9 record. $ nslookup server 10.1.20.9 Default server: 10.1.20.9 Address: 10.1.20.9#53 10.1.20.9 Server:10.1.20.9 Address:10.1.20.9#53 9.20.1.10.in-addr.arpaname = prd-ops-ipa01.uzb.local. 10.1.0.9 Server:10.1.20.9 Address:10.1.20.9#53 ** server can't find 9.0.1.10.in-addr.arpa.: NXDOMAIN *BELOW IS WITH FORWARDING ENABLED*. It cannot find 10.1.20.9 but can find 10.1.0.9. This is expected as the forwarding server only has the 10.1.0.9 record. 10.1.20.9 Server:10.1.20.9 Address:10.1.20.9#53 ** server can't find 9.20.1.10.in-addr.arpa.: NXDOMAIN 10.1.0.9 Server:10.1.20.9 Address:10.1.20.9#53 Non-authoritative answer: 9.0.1.10.in-addr.arpaname = ops-ipa01.bbf.local. Authoritative answers can be found from: 1.10.in-addr.arpanameserver = ops-ipa01.bbf.local. *BELOW IS WITH FORWARD FIRST ENABLED*. It cannot find 10.1.20.9 but can find 10.1.0.9. This is un-expected as the local zone has the 10.1.20.9 and the forward server has the 10.1.0.9 so we should be getting both. 10.1.20.9 Server:10.1.20.9 Address:10.1.20.9#53 ** server can't find 9.20.1.10.in-addr.arpa.: NXDOMAIN 10.1.0.9 Server:10.1.20.9 Address:10.1.20.9#53 Non-authoritative answer: 9.0.1.10.in-addr.arpaname = ops-ipa01.bbf.local. Authoritative answers can be found from: 1.10.in-addr.arpanameserver = ops-ipa01.bbf.local. ops-ipa01.bbf.localinternet address = 10.1.0.9 Any help is greatly appreciated. Thanks, Shaun Shaun Martin IT\OPS Manager Black Duck Software O: +1.781.425.4336 Black Duck Software http://www.blackducksoftware.com/ | OpenHUB https://www.openhub.net/ | OSDelivers http://osdelivers.blackducksoftware.com/ | OSS Logistics https://www.blackducksoftware.com/oss-logistics http://twitter.com/black_duck_swhttps://www.linkedin.com/company/black-duck-softwarehttps://www.facebook.com/BlackDuckSoftwarehttps://plus.google.com/+Blackducksoftware/http://www.slideshare.net/blackducksoftware /JP Morgan Chase Co. Hall of Innovation Inductee/ https://www.youtube.com/user/BlackDuckSoftware Hello, we need more info: do you use global forwarders, or zone forwarders? how your reverse zones are configured (name, delegation)? Default forwarding policy is first, IMO both of your examples with forwarding enabled are forwarding first policy. Martin -- Martin Basti -- 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] [Solaris 10] Cannot login through console or ssh with ipa users
I am having trouble logging in with an IPA user on Solaris 10. The machine is able to correctly initialize tickets using kinit. The issue appears to be PAM related. I am using FreeIPA 4.1.3. I have tried to follow the instructions here as best I can : http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html Here is my kinit and klist tests $ kinit ipauser1 Password for ipaus...@ipadomain.net: [07:45 PM] ipaclient5-sandbox-atdev-van:/var/log$ klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: ipaus...@ipadomain.net Valid startingExpiresService principal 02/25/15 19:45:10 02/26/15 19:45:10 krbtgt/ipadomain@ipadomain.net renew until 03/04/15 19:45:10 Here is the last 2 lines of the output of getent passwd showing my ipa admin and user - admin:x:37520:37520:Administrator:/home/admin:/bin/bash ipauser1:x:37526:37526:ipa user1:/home/ipauser1:/bin/bash However, this is what happens when I try to login as 'ipauser1'. On the console I am prompted with 'Password:' I enter the valid password, and suddenly Putty pops up a window 'Server unexpectedly closed network connection'. If I try to login as ipaus...@ipadomain.net it still fails, but in a different way. The putty window stays open and I get an 'Access denied' message and am prompted for the password again: Logs with 'ipauser1' Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.info] Connection from 10.5.5.57 port 57607 on 10.21.19.16 port 22 Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: Client protocol version 2.0; client software version PuTTY_Release_0.63 Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: no match: PuTTY_Release_0.63 Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: Enabling compatibility mode for protocol 2.0 Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: Local version string SSH-2.0-OpenSSH_6.6 Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: permanently_set_uid: 100/65534 [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEXINIT sent [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEXINIT received [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: kex: client-server aes256-ctr hmac-sha2-256 none [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: kex: server-client aes256-ctr hmac-sha2-256 none [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID 800047 auth.debug] debug1: server_input_channel_req: channel 0 request win...@putty.projects.tartarus.org reply 1 Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID 800047 auth.debug] debug1: session_by_channel: session 0 channel 0 Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID 800047 auth.debug] debug1: session_input_channel_req: session 0 req win...@putty.projects.tartarus.org Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: SSH2_MSG_NEWKEYS sent [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: expecting SSH2_MSG_NEWKEYS [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: SSH2_MSG_NEWKEYS received [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: KEX done [preauth] Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: userauth-request for user ipauser1 service ssh-connection method
Re: [Freeipa-users] Web UI plugins or other extensions
On 2/25/2015 11:02 AM, Dmitri Pal wrote: But let us step back and ask the question why do you need to create the users you sync manually first? The users in a specific OU will be synced anyways without you manually creating them in IPA. So this is unclear why the whole thing is actually needed. What we'd like to do is have admins create users in IPA via the web interface (or CLI, if they're so inclined) and add them to an IPA group then have those users synched over to our AD environment, so those users can log into their Windows workstations. We'd like to avoid duplicate or unnecessary effort in terms of creating users. More steps to a process = more likelihood of mistakes. We'd like to create the users in IPA so that we're consistent in everyone using the IPA web interface to manage their user accounts. Thanks, Hugh -- 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] Forward first not working
On 25/02/15 18:51, Shaun Martin wrote: Hi Martin, The zone name is the following for both servers. Zone name: 1.10.in-addr.arpa. I am using zone forwarders. With forward first enabled though it should try and return an answer from the local DNS, it clearly does not though. The only time I receive the local record is when forwarding is disabled. Thanks, Shaun Shaun Martin IT\OPS Manager Black Duck Software O: +1.781.425.4336 Black Duck Software http://www.blackducksoftware.com/ | OpenHUB https://www.openhub.net/ | OSDelivers http://osdelivers.blackducksoftware.com/ | OSS Logistics https://www.blackducksoftware.com/oss-logistics http://twitter.com/black_duck_swhttps://www.linkedin.com/company/black-duck-softwarehttps://www.facebook.com/BlackDuckSoftwarehttps://plus.google.com/+Blackducksoftware/http://www.slideshare.net/blackducksoftware /JP Morgan Chase Co. Hall of Innovation Inductee/ https://www.youtube.com/user/BlackDuckSoftware On Feb 25, 2015, at 12:42 PM, Martin Basti mba...@redhat.com mailto:mba...@redhat.com wrote: On 25/02/15 17:59, Shaun Martin wrote: Hi, I am having an issue with the forward first not appear to be working. I have two separate IPA servers that server separate realms. I have for the reverse zone configured forwarders to point to the other realms IPA server. All versions are identical on the IPA servers. I have included details on version and tests that show this is not working. $ yum list installed |grep bind-dyndb-ldap bind-dyndb-ldap.x86_64 3.5-4.el7 @base $ yum list installed |grep ipa ipa-admintools.x86_64 3.3.3-28.0.1.el7.centos.3 @updates ipa-client.x86_64 3.3.3-28.0.1.el7.centos.3 @updates ipa-python.x86_64 3.3.3-28.0.1.el7.centos.3 @updates ipa-server.x86_64 3.3.3-28.0.1.el7.centos.3 @updates libipa_hbac.x86_64 1.11.2-68.el7_0.6 @updates libipa_hbac-python.x86_64 1.11.2-68.el7_0.6 @updates python-iniparse.noarch 0.4-9.el7 @anaconda sssd-ipa.x86_64 *BELOW IS WITH FORWARDING DISABLED*. It cannot find 10.1.0.9 but can find 10.1.20.9. This is expected as this server only has the 10.1.20.9 record. $ nslookup server 10.1.20.9 Default server: 10.1.20.9 Address: 10.1.20.9#53 10.1.20.9 Server:10.1.20.9 Address:10.1.20.9#53 9.20.1.10.in-addr.arpaname = prd-ops-ipa01.uzb.local. 10.1.0.9 Server:10.1.20.9 Address:10.1.20.9#53 ** server can't find 9.0.1.10.in-addr.arpa.: NXDOMAIN *BELOW IS WITH FORWARDING ENABLED*. It cannot find 10.1.20.9 but can find 10.1.0.9. This is expected as the forwarding server only has the 10.1.0.9 record. 10.1.20.9 Server:10.1.20.9 Address:10.1.20.9#53 ** server can't find 9.20.1.10.in-addr.arpa.: NXDOMAIN 10.1.0.9 Server:10.1.20.9 Address:10.1.20.9#53 Non-authoritative answer: 9.0.1.10.in-addr.arpaname = ops-ipa01.bbf.local. Authoritative answers can be found from: 1.10.in-addr.arpanameserver = ops-ipa01.bbf.local. *BELOW IS WITH FORWARD FIRST ENABLED*. It cannot find 10.1.20.9 but can find 10.1.0.9. This is un-expected as the local zone has the 10.1.20.9 and the forward server has the 10.1.0.9 so we should be getting both. 10.1.20.9 Server:10.1.20.9 Address:10.1.20.9#53 ** server can't find 9.20.1.10.in-addr.arpa.: NXDOMAIN 10.1.0.9 Server:10.1.20.9 Address:10.1.20.9#53 Non-authoritative answer: 9.0.1.10.in-addr.arpaname = ops-ipa01.bbf.local. Authoritative answers can be found from: 1.10.in-addr.arpanameserver = ops-ipa01.bbf.local. ops-ipa01.bbf.localinternet address = 10.1.0.9 Any help is greatly appreciated. Thanks, Shaun Mail Attachment.png Shaun Martin IT\OPS Manager Black Duck Software O: +1.781.425.4336 Black Duck Software http://www.blackducksoftware.com/ | OpenHUB https://www.openhub.net/ | OSDelivers http://osdelivers.blackducksoftware.com/ | OSS Logistics https://www.blackducksoftware.com/oss-logistics Mail Attachment.pnghttp://twitter.com/black_duck_swMail Attachment.pnghttps://www.linkedin.com/company/black-duck-softwareMail Attachment.pnghttps://www.facebook.com/BlackDuckSoftwareMail Attachment.pnghttps://plus.google.com/+Blackducksoftware/Mail Attachment.pnghttp://www.slideshare.net/blackducksoftwareMail Attachment.png /JP Morgan Chase Co. Hall of Innovation Inductee/ https://www.youtube.com/user/BlackDuckSoftware Hello, we need more info: do you use global forwarders, or zone forwarders? how your reverse zones are configured (name, delegation)? Default forwarding policy is first, IMO both of your examples with forwarding enabled are forwarding first policy. Martin -- Martin Basti You issue is, the IPA 4.1, separate zones in following way: * zone with forwarders specified == forward zone, records inside are ignored * zone without forwarders, or zone with --forward-policy=none == master zone, no forwarding So if you specify forwarders, your zone works as BIND's forward zone without records. And
Re: [Freeipa-users] Web UI plugins or other extensions
On 02/25/2015 01:22 PM, Hugh wrote: On 2/25/2015 11:02 AM, Dmitri Pal wrote: But let us step back and ask the question why do you need to create the users you sync manually first? The users in a specific OU will be synced anyways without you manually creating them in IPA. So this is unclear why the whole thing is actually needed. What we'd like to do is have admins create users in IPA via the web interface (or CLI, if they're so inclined) and add them to an IPA group then have those users synched over to our AD environment, so those users can log into their Windows workstations. We'd like to avoid duplicate or unnecessary effort in terms of creating users. More steps to a process = more likelihood of mistakes. We'd like to create the users in IPA so that we're consistent in everyone using the IPA web interface to manage their user accounts. Thanks, Hugh Will all users created via IPA interface synched to AD? Is there any harm to make all users be created with the attributes mentioned earlier in this thread? -- 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] [Solaris 10] Cannot login through console or ssh with ipa users
On 02/25/2015 02:58 PM, nat...@nathanpeters.com wrote: I am having trouble logging in with an IPA user on Solaris 10. The machine is able to correctly initialize tickets using kinit. The issue appears to be PAM related. I am using FreeIPA 4.1.3. I have tried to follow the instructions here as best I can : http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html Here is my kinit and klist tests $ kinit ipauser1 Password for ipaus...@ipadomain.net: [07:45 PM] ipaclient5-sandbox-atdev-van:/var/log$ klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: ipaus...@ipadomain.net Valid startingExpiresService principal 02/25/15 19:45:10 02/26/15 19:45:10 krbtgt/ipadomain@ipadomain.net renew until 03/04/15 19:45:10 Here is the last 2 lines of the output of getent passwd showing my ipa admin and user - admin:x:37520:37520:Administrator:/home/admin:/bin/bash ipauser1:x:37526:37526:ipa user1:/home/ipauser1:/bin/bash However, this is what happens when I try to login as 'ipauser1'. On the console I am prompted with 'Password:' I enter the valid password, and suddenly Putty pops up a window 'Server unexpectedly closed network connection'. If I try to login as ipaus...@ipadomain.net it still fails, but in a different way. The putty window stays open and I get an 'Access denied' message and am prompted for the password again: Logs with 'ipauser1' Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.info] Connection from 10.5.5.57 port 57607 on 10.21.19.16 port 22 Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: Client protocol version 2.0; client software version PuTTY_Release_0.63 Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: no match: PuTTY_Release_0.63 Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: Enabling compatibility mode for protocol 2.0 Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: Local version string SSH-2.0-OpenSSH_6.6 Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: permanently_set_uid: 100/65534 [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEXINIT sent [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEXINIT received [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: kex: client-server aes256-ctr hmac-sha2-256 none [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: kex: server-client aes256-ctr hmac-sha2-256 none [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID 800047 auth.debug] debug1: server_input_channel_req: channel 0 request win...@putty.projects.tartarus.org reply 1 Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID 800047 auth.debug] debug1: session_by_channel: session 0 channel 0 Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[538]: [ID 800047 auth.debug] debug1: session_input_channel_req: session 0 req win...@putty.projects.tartarus.org Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: SSH2_MSG_NEWKEYS sent [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: expecting SSH2_MSG_NEWKEYS [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: SSH2_MSG_NEWKEYS received [preauth] Feb 25 19:46:41 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1: KEX done [preauth] Feb 25 19:46:54 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[761]: [ID 800047 auth.debug] debug1:
[Freeipa-users] [SSSD] default_domain_suffix breaks IPA user logins
FreeIPA Server 4.1.2 FreeIPA client 3.0.0-42 I'm not sure how to go about fixing this or working around it. In our organization we have a trust relationship between ad.somedomain.net and ipadomain.net. We don't want our AD users having to type usern...@ad.somedomain.net when logging in to an IPA machine so we have added default_domain_suffix = ad.somedomain.net to the [sssd] section of sssd.conf. This works great when logging in with an AD user. I can login using 'username' and they end up with the proper shell and home directory /home/ad.somedomain.net/username etc. However, when I try to login with an IPA user using the username ipau...@ipadomain.net I am just disconnected. Removing the default_domain_suffix line immediately fixes , but then we lose the ability to login with AD users just typing their username. Does anyone know how to fix this / workaround it so we can use the default_domain_suffix option and not break internal FreeIPA user logins? -- 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] Web UI plugins or other extensions
On 02/25/2015 02:15 PM, Hugh wrote: On 2/25/2015 12:50 PM, Dmitri Pal wrote: Will all users created via IPA interface synched to AD? Is there any harm to make all users be created with the attributes mentioned earlier in this thread? Almost all. We have some users that will be role accounts for various pieces of software. It's fine with me if all users by default get those attributes and for those that shouldn't we can manually go back and remove the object/attributes. Hugh I think you can start with adding ntUser object class into the list of the object classes in the IPA configuration in UI. That would apply it to the new entries automatically. If that does not work it is probably a bug. If it works you will have the object class right there. Next step is creating attributes - ntUserDomainId - I wonder whether it can be auto-populated using managed entry or CoS configuration in DS. If that works it will be a config change rather than a code change which means it will survive upgrades (most likely). - ntUserCreateNewAccount - should be set to true AFAIU and I wonder if it can be set to true using same managed entry or CoS mechanism. I am not saying that would work but that might work and would avoid doing code changes. If you willing to do code changes than it should be possible to just update the user plugin to autopopulate the entries with these attributes. But that would definitely blow up during upgrade. -- 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] [Solaris 10] Cannot login through console or ssh with ipa users
It does not seem to recognize the user in the secan attempt but the first attempt seems to authenticate and then disconnect. I do not see trace from accounting session but I suspect that your pam stack does not authorize authenticated user. Try to allow all authenticated users first. This will prove that it is a pam stack accounting phase configuration issue. -- 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 How do I allow all authenticated users? In the freeIPA domain I have a rule 'allow_all' that allows any user to connect to any system on any service. This is working fine for linux clients. I assume you mean to do it on the Solaris machine? I don't have any users specifically blocked, ie, there is nothing in my sshd_config file that is limiting the users and groups that can login. Eg, I've got no 'AllowUsers' lines or anything like that. I've even got PermitRootLogin set to yes and have tested that root can login. -- 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] [SSSD] default_domain_suffix breaks IPA user logins
On Wed, Feb 25, 2015 at 12:11:10PM -0800, nat...@nathanpeters.com wrote: FreeIPA Server 4.1.2 FreeIPA client 3.0.0-42 I'm not sure how to go about fixing this or working around it. In our organization we have a trust relationship between ad.somedomain.net and ipadomain.net. We don't want our AD users having to type usern...@ad.somedomain.net when logging in to an IPA machine so we have added default_domain_suffix = ad.somedomain.net to the [sssd] section of sssd.conf. This works great when logging in with an AD user. I can login using 'username' and they end up with the proper shell and home directory /home/ad.somedomain.net/username etc. However, when I try to login with an IPA user using the username ipau...@ipadomain.net I am just disconnected. Removing the default_domain_suffix line immediately fixes , but then we lose the ability to login with AD users just typing their username. Does anyone know how to fix this / workaround it so we can use the default_domain_suffix option and not break internal FreeIPA user logins? Known issue: https://fedorahosted.org/sssd/ticket/2569 I just acked a patch by Michal Zidek that fixes the problem. In the meantime, you can set: use_fully_qualified_names = True in the [domain] section. -- 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] [Solaris 10] Cannot login through console or ssh with ipa users
It does not seem to recognize the user in the secan attempt but the first attempt seems to authenticate and then disconnect. I do not see trace from accounting session but I suspect that your pam stack does not authorize authenticated user. Try to allow all authenticated users first. This will prove that it is a pam stack accounting phase configuration issue. -- 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 I'm not sure how to enable a trace for an accounting session. Here is what I've done to enable debugging so far : add the following line to /etc/syslog.conf *.debug /var/log/pam_log svcadm restart system-log touch /etc/pam_debug cat debug_flags=65535 /etc/pam_debug I have a little more debugging info now than before, but it still stops at the krb5 line. See below for more detailed log. Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: Client protocol version 2.0; client software version PuTTY_Release_0.63 Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: no match: PuTTY_Release_0.63 Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: Enabling compatibility mode for protocol 2.0 Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: Local version string SSH-2.0-OpenSSH_6.6 Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: permanently_set_uid: 100/65534 [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEXINIT sent [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEXINIT received [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: kex: client-server aes256-ctr hmac-sha2-256 none [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: kex: server-client aes256-ctr hmac-sha2-256 none [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: SSH2_MSG_NEWKEYS sent [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: expecting SSH2_MSG_NEWKEYS [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: SSH2_MSG_NEWKEYS received [preauth] Feb 25 22:53:02 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: KEX done [preauth] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: userauth-request for user ipauser1 service ssh-connection method none [preauth] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: attempt 0 failures 0 [preauth] Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 800047 auth.debug] debug1: PAM: initializing for ipauser1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 489767 auth.debug] PAM[938]: pam_start(sshd,ipauser1,811c170:812b8e0) - debug = Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 984622 auth.debug] PAM[938]: pam_set_item(812b8e0:service)=sshd Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 984622 auth.debug] PAM[938]: pam_set_item(812b8e0:user)=ipauser1 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 984619 auth.debug] PAM[938]: pam_set_item(812b8e0:conv)=8086ff8 Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 960046 auth.debug] PAM[938]: pam_get_item(812b8e0:service)=sshd Feb 25 22:53:05 ipaclient5-sandbox-atdev-van.ipadomain.net sshd[938]: [ID 102344 auth.debug] PAM[938]: pam.conf entry:login auth requisite pam_authtok_get.so.1 Feb 25 22:53:05
Re: [Freeipa-users] 2-Factor and services
Hi, So pass authentication to a RSA radius server and key fobs? Looks like RHEL7.1 can do this, I am waiting for its release to do just this. regards Steven Jones B.Eng (Hons) Technical Specialist - Linux RHCE Victoria University ITS, Level 8 Rankin Brown Building, Wellington, NZ 6012 0064 4 463 6272 From: freeipa-users-boun...@redhat.com freeipa-users-boun...@redhat.com on behalf of Matt Wells matt.we...@mosaic451.com Sent: Thursday, 26 February 2015 10:54 a.m. To: freeipa-users@redhat.com Subject: [Freeipa-users] 2-Factor and services I've got many of users setup with 2-Factor and I'd like to enforce it with some services. For example. Server vpn.example.comhttp://vpn.example.com is an openvpn servers setup to use PAM. Since he's tied to my 4.X IDM servers I can use 2-Factor with him. However I want to enforce that users from this system/service require 2-Factor. Can anyone point me in the right direction? My Google Foo is showing to be poor on this one and any guidance would be appreciated. As always thanks for taking the time to read over this. -- 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] ipa-getcert list fails to report correctly - RESOLVED
-Original Message- From: Martin Kosek [mailto:mko...@redhat.com] Sent: Wednesday, 25 February 2015 10:35 PM To: Les Stott; Rob Crittenden; freeipa-users@redhat.com; Endi Dewata; Jan Cholasta Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly - RESOLVED On 02/25/2015 03:11 AM, Les Stott wrote: -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Les Stott Sent: Monday, 23 February 2015 8:01 PM To: Rob Crittenden; Martin Kosek; freeipa-users@redhat.com; Endi Dewata; Jan Cholasta Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Les Stott Sent: Monday, 23 February 2015 12:18 PM To: Rob Crittenden; Martin Kosek; freeipa-users@redhat.com; Endi Dewata; Jan Cholasta Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: Saturday, 21 February 2015 1:39 AM To: Martin Kosek; Les Stott; freeipa-users@redhat.com; Endi Dewata; Jan Cholasta Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly Martin Kosek wrote: On 02/20/2015 06:56 AM, Les Stott wrote: Hi all, The following is blocking the ability for me to install a CA replica. Environment: RHEL 6.6 IPA 3.0.0-42 PKI 9.0.3-38 On the master the following is happening: ipa-getcert list Number of certificates and requests being tracked: 5. (but it shows no certificate details in the output) Running getcert list shows complete output. Also, when trying to browse https://master.mydomain.com/ca/ee/ca/getCertChain i get a failed response. The apache error logs on the master show [Thu Feb 19 23:23:23 2015] [error] SSL Library Error: -12271 SSL client cannot verify your certificate The reason I am trying to browse that address is because that's what the ipa-ca-install setup is failing at (it complains that the CA certificate is not in proper format, in fact it's not able to get it at all). I know from another working ipa setup that Browsing to the above address provides valid xml content and ipa-getcert list shows certificate details and not just the number of tracked certificates. Been trying for a long time to figure out the issues without luck. I would greatly appreciate any help to troubleshoot and resolve the above issues. Regards, Les Endi or JanC, would you have any advise for Les? To me, it looks like the Apache does not have proper certificate installed. My ipa-getcert on RHEL-6.6 shows 3 Server-Certs tracked, making it in total of 8 certs tracked: # ipa-getcert list Number of certificates and requests being tracked: 8. Request ID '201402': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- COM',nicknam e='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- COM',nicknam e='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=vm-086.example.com,O=EXAMPLE.COM expires: 2016-11-11 00:00:01 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '201447': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server- Cert' ,token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server- Cert' ,token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=vm-086.example.com,O=EXAMPLE.COM expires: 2016-11-11 00:00:46 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '2014000302': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',toke n= 'N SS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',toke n= 'N SS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=vm-086.example.com,O=EXAMPLE.COM
Re: [Freeipa-users] ipa-getcert list fails to report correctly - RESOLVED
On 2/26/2015 8:02 AM, Les Stott wrote: rm -rf /etc/pki-ca /var/lib/pki-ca /var/log/pki-ca /etc/certmonger /etc/sysconfig/pki-ca /etc/sysconfig/pki /var/run/pki-ca.pid /usr/share/pki /etc/ipa /var/log/ipa* reboot Now you have a clean slate. Do you know which step of the steps above actually helped you resolve the reinstall issue? The reboot I think was key to the whole process, but pki remnants seemed left behind too which caused grief. Previously I had never rebooted the system in between uninstall/reinstall. /etc/ipa/ca.crt was also left behind. It caused an issue during one reinstall as it never got updated and the install bombed out because it found a mismatched cert. This led me to deleting all possible ipa/pki directories and then removing/reinstalling rpms to restore to default state. I noticed that in some cases (I went through this same process on 6 servers to reinstall and setup CA replicas) I could still see a left over process running as the pkiuser (tomcat/java) which stopped the userdel pkiuser command from completing. I had to kill that process and then userdel pkiuser worked. Some of the above files/folders should have been removed automatically when the Dogtag instance/package is removed. There's already a ticket to improve this on Dogtag 10: https://fedorahosted.org/pki/ticket/1172 I created a new ticket for Dogtag 9: https://fedorahosted.org/pki/ticket/1280 Thanks! -- Endi S. Dewata -- 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] Web UI plugins or other extensions
On 2/25/2015 3:11 PM, Dmitri Pal wrote: I think you can start with adding ntUser object class into the list of the object classes in the IPA configuration in UI. That would apply it to the new entries automatically. How is that done? I'd rather not have to tweak the package files, since that will cause upgrades to be problematic, as you and Petr said. If that does not work it is probably a bug. If it works you will have the object class right there. Next step is creating attributes - ntUserDomainId - I wonder whether it can be auto-populated using managed entry or CoS configuration in DS. If that works it will be a config change rather than a code change which means it will survive upgrades (most likely). - ntUserCreateNewAccount - should be set to true AFAIU and I wonder if it can be set to true using same managed entry or CoS mechanism. I am not saying that would work but that might work and would avoid doing code changes. I couldn't find any decent documentation on managed entries or class of service functionality. Can you point me in the right direction? If you willing to do code changes than it should be possible to just update the user plugin to autopopulate the entries with these attributes. But that would definitely blow up during upgrade. Yeah, that's pretty far down on the list of options for this project. But, you never know ... Hugh -- 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] [Solaris 10] Cannot login through console or ssh with ipa users
On 02/25/2015 04:37 PM, nat...@nathanpeters.com wrote: It does not seem to recognize the user in the secan attempt but the first attempt seems to authenticate and then disconnect. I do not see trace from accounting session but I suspect that your pam stack does not authorize authenticated user. Try to allow all authenticated users first. This will prove that it is a pam stack accounting phase configuration issue. -- 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 How do I allow all authenticated users? In the freeIPA domain I have a rule 'allow_all' that allows any user to connect to any system on any service. This is working fine for linux clients. I assume you mean to do it on the Solaris machine? I don't have any users specifically blocked, ie, there is nothing in my sshd_config file that is limiting the users and groups that can login. Eg, I've got no 'AllowUsers' lines or anything like that. I've even got PermitRootLogin set to yes and have tested that root can login. other accountrequired pam_permit.so and comment other pam modules in the section: Default definition for Account management # Used when service name is not explicitly mentioned for account management # other account requisite pam_roles.so.1 debug other account requiredpam_unix_account.so.1 debug #other account sufficient pam_ldap.so.1 other account requiredpam_krb5.so.1 debug -- 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
[Freeipa-users] 2-Factor and services
I've got many of users setup with 2-Factor and I'd like to enforce it with some services. For example. Server vpn.example.com is an openvpn servers setup to use PAM. Since he's tied to my 4.X IDM servers I can use 2-Factor with him. However I want to enforce that users from this system/service require 2-Factor. Can anyone point me in the right direction? My Google Foo is showing to be poor on this one and any guidance would be appreciated. As always thanks for taking the time to read over this. -- 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] Web UI plugins or other extensions
On 02/25/2015 05:39 PM, Hugh wrote: On 2/25/2015 3:11 PM, Dmitri Pal wrote: I think you can start with adding ntUser object class into the list of the object classes in the IPA configuration in UI. That would apply it to the new entries automatically. How is that done? I'd rather not have to tweak the package files, since that will cause upgrades to be problematic, as you and Petr said. Log into UI. Go to IPA Server - Configuration. See default user objectclasses, add a new one: ntUser. Save configuration. Add a new user in UI or command line. Check his object classes with --raw using command line. Is should now that an entry has a new object class applied to it. But I just checked the schema objectClasses: ( 2.16.840.1.113730.3.2.8 NAME 'ntUser' DESC 'Netscape defined objectclass' SUP top MUST ( ntUserDomainId ) MAY ( description $ l $ ou $ seeAlso $ ntUserPriv $ ntUserHomeDir $ ntUserComment $ ntUserFlags $ ntUserScriptPath $ ntUserAuthFlags $ ntUserUsrComment $ ntUserParms $ ntUserWorkstations $ ntUserLastLogon $ ntUserLastLogoff $ ntUserAcctExpires $ ntUserMaxStorage $ ntUserUnitsPerWeek $ ntUserLogonHours $ ntUserBadPwCount $ ntUserNumLogons $ ntUserLogonServer $ ntUserCountryCode $ ntUserCodePage $ ntUserUniqueId $ ntUserPrimaryGroupId $ ntUserProfile $ ntUserHomeDirDrive $ ntUserPasswordExpired $ ntUserCreateNewAccount $ ntUserDeleteAccount $ ntUniqueId) X-ORIGIN 'Netscape NT Synchronization' ) ntUserDomainId is a required attribute so IPA will be broken. To overcome it you might want to make it non mandatory i.e. objectClasses: ( 2.16.840.1.113730.3.2.8 NAME 'ntUser' DESC 'Netscape defined objectclass' SUP top MAY ( ntUserDomainId $ description $ l $ ou $ seeAlso $ ntUserPriv $ ntUserHomeDir $ ntUserComment $ ntUserFlags $ ntUserScriptPath $ ntUserAuthFlags $ ntUserUsrComment $ ntUserParms $ ntUserWorkstations $ ntUserLastLogon $ ntUserLastLogoff $ ntUserAcctExpires $ ntUserMaxStorage $ ntUserUnitsPerWeek $ ntUserLogonHours $ ntUserBadPwCount $ ntUserNumLogons $ ntUserLogonServer $ ntUserCountryCode $ ntUserCodePage $ ntUserUniqueId $ ntUserPrimaryGroupId $ ntUserProfile $ ntUserHomeDirDrive $ ntUserPasswordExpired $ ntUserCreateNewAccount $ ntUserDeleteAccount $ ntUniqueId) X-ORIGIN 'Netscape NT Synchronization' ) It can be found in the 50ns-directory.ldif If that does not work it is probably a bug. If it works you will have the object class right there. Next step is creating attributes - ntUserDomainId - I wonder whether it can be auto-populated using managed entry or CoS configuration in DS. If that works it will be a config change rather than a code change which means it will survive upgrades (most likely). - ntUserCreateNewAccount - should be set to true AFAIU and I wonder if it can be set to true using same managed entry or CoS mechanism. I am not saying that would work but that might work and would avoid doing code changes. I couldn't find any decent documentation on managed entries or class of service functionality. Can you point me in the right direction? http://directory.fedoraproject.org/docs/389ds/howto/howto-classofservice.html http://www.port389.org/docs/389ds/design/managed-entry-design.html But a quick look does not seem to render what we need to do here. So here is a workaround. Create a script that will using CLI. List all the users that have ntUser object class but do not have ntUserDomainId set. If you find such entries set proper attributes using ipa user-mod command. Run it as a cron job every 5 min or so. You can also make it smarter in future to deal with your special cases. For example if your special users follow some naming convention you can instead of adding attributes strip the object class. This is the best I was able to come up with :-) If you willing to do code changes than it should be possible to just update the user plugin to autopopulate the entries with these attributes. But that would definitely blow up during upgrade. Yeah, that's pretty far down on the list of options for this project. But, you never know ... Hugh -- 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] 2-Factor and services
On 02/25/2015 04:54 PM, Matt Wells wrote: I've got many of users setup with 2-Factor and I'd like to enforce it with some services. For example. Server vpn.example.com http://vpn.example.com is an openvpn servers setup to use PAM. Since he's tied to my 4.X IDM servers I can use 2-Factor with him. However I want to enforce that users from this system/service require 2-Factor. Can anyone point me in the right direction? My Google Foo is showing to be poor on this one and any guidance would be appreciated. As always thanks for taking the time to read over this. So do you want to use 2FA for some users and 1FA for others or do you want to have flexibility to use 2FA for the same user on one system and not another? Do you plan to use external tokens like RSA or you plan to use native OTP support in IPA? -- 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] ipa-getcert list fails to report correctly - RESOLVED
-Original Message- From: Endi Sukma Dewata [mailto:edew...@redhat.com] Sent: Thursday, 26 February 2015 1:50 AM To: Martin Kosek Cc: Les Stott; Rob Crittenden; freeipa-users@redhat.com; Jan Cholasta Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly - RESOLVED On 2/25/2015 6:35 PM, Martin Kosek wrote: yum -y remove pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util pki-native-tools ipa-server-selinux ipa-server ipa-client ipa-admintools ipa-python ipa-pki-ca-theme ipa-pki-common-theme 389-ds-base 389-ds-base-libs userdel pkisrv userdel pkiuser This should not be needed at all, AFAIK. This may not be related to this problem, but sometimes reinstalling the packages is necessary to resolve installation problem. For example: https://fedorahosted.org/freeipa/ticket/4591 In this ticket reinstalling 389-ds-base will recreate the missing folder. I didn't actually see this issue when I ran thought reinstall, but then I did remove and reinstall 389-ds-base which would have re-created it. Regards, Les -- 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] ipa-getcert list fails to report correctly - RESOLVED
On 02/25/2015 03:11 AM, Les Stott wrote: -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Les Stott Sent: Monday, 23 February 2015 8:01 PM To: Rob Crittenden; Martin Kosek; freeipa-users@redhat.com; Endi Dewata; Jan Cholasta Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Les Stott Sent: Monday, 23 February 2015 12:18 PM To: Rob Crittenden; Martin Kosek; freeipa-users@redhat.com; Endi Dewata; Jan Cholasta Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: Saturday, 21 February 2015 1:39 AM To: Martin Kosek; Les Stott; freeipa-users@redhat.com; Endi Dewata; Jan Cholasta Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly Martin Kosek wrote: On 02/20/2015 06:56 AM, Les Stott wrote: Hi all, The following is blocking the ability for me to install a CA replica. Environment: RHEL 6.6 IPA 3.0.0-42 PKI 9.0.3-38 On the master the following is happening: ipa-getcert list Number of certificates and requests being tracked: 5. (but it shows no certificate details in the output) Running getcert list shows complete output. Also, when trying to browse https://master.mydomain.com/ca/ee/ca/getCertChain i get a failed response. The apache error logs on the master show [Thu Feb 19 23:23:23 2015] [error] SSL Library Error: -12271 SSL client cannot verify your certificate The reason I am trying to browse that address is because that's what the ipa-ca-install setup is failing at (it complains that the CA certificate is not in proper format, in fact it's not able to get it at all). I know from another working ipa setup that Browsing to the above address provides valid xml content and ipa-getcert list shows certificate details and not just the number of tracked certificates. Been trying for a long time to figure out the issues without luck. I would greatly appreciate any help to troubleshoot and resolve the above issues. Regards, Les Endi or JanC, would you have any advise for Les? To me, it looks like the Apache does not have proper certificate installed. My ipa-getcert on RHEL-6.6 shows 3 Server-Certs tracked, making it in total of 8 certs tracked: # ipa-getcert list Number of certificates and requests being tracked: 8. Request ID '201402': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- COM',nicknam e='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- COM',nicknam e='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=vm-086.example.com,O=EXAMPLE.COM expires: 2016-11-11 00:00:01 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '201447': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server- Cert' ,token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server- Cert' ,token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=vm-086.example.com,O=EXAMPLE.COM expires: 2016-11-11 00:00:46 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '2014000302': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',toke n= 'N SS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',toke n= 'N SS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=vm-086.example.com,O=EXAMPLE.COM expires: 2016-11-11 00:03:02 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes What is actually in your Apache NSS database? # certutil -L -d /etc/httpd/alias/ Martin Remember ipa-getcert is just a shortcut for certificates using the certmonger CA named IPA, so it's more a filter
