[Freeipa-users] Re: New clients doesn't allow to use AD users with shortnames and showing the users/groups also with short names
On Wed, Nov 21, 2018 at 02:22:51PM +, SOLER SANGUESA Miguel via FreeIPA-users wrote: > I've been working for 1 year with a configuration that allow us to use AD > users with short names for login on RHEL 6 clients and also the information > on the client was showed with shortnames. Example: This doesn't work in general on RHEL-6. I don't know why it ever did, for you and I'm suprised it did, but in general, short name output is only supported in never versions that RHEL-6 ships. And even in RHEL-7+ it is /strongly/ discouraged to use shortnames in output. The only thing that RHEL-6 supports in this respect is the default_domain_suffix option, but the output will always be qualified. Sorry. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Migration from Test to Production
On 21.11.18 17:40, Rob Crittenden via FreeIPA-users wrote: [..] Yes, masters are all more or less equal, the difference being whether they run optional services and there are a few roles that only one master has (CRL manager, renewal manager). I still do not have a clear picture. Is it true that any scenario starts with one master and all others are replicas? What about AD trust? Does it have to be set up for each of the new servers? https://www.freeipa.org/page/Active_Directory_trust_setup does say so: "When planning access of AD users to IPA clients, make sure to run ipa-adtrust-install on every IPA master these IPA clients will be connecting to." Then I guess it does. Can anyone confirm this? Cheers, Ron ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Migration from Test to Production
On 19.10.18 14:15, Rob Crittenden via FreeIPA-users wrote: Ronald Wimmer via FreeIPA-users wrote: Hi, we have been evaluating FreeIPA for quite a while now on our test setup (1 IPA server, 1 Replica) and are planning to move towards production. Can the whole setup be migrated from an ipa test to an ipa production server? (the ipa 'linux.ourdomain.at' domain should stay the same) Or would it be easier to use both test servers for production (and just adding additional replicas)? There is no real migration mechanism between environments like you're looking for (e.g. test -> integration -> production). IMHO you are best off putting these systems into production and perhaps adding additional masters. How do I add new production servers? Simply issue the "ipa-replica-install" on the new systems? (The documentation states: "Replicas are created as clones of the initial master servers. Once a replica is created, it is functionally identical to the master server") What about AD trust? Does it have to be set up for each of the new servers? https://www.freeipa.org/page/Active_Directory_trust_setup does say so: "When planning access of AD users to IPA clients, make sure to run ipa-adtrust-install on every IPA master these IPA clients will be connecting to." Does it make sense to install CA services on each of the servers? Cheers, Ronald ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Is the admins group special?
Remco Kranenburg via FreeIPA-users wrote: > Hi all, > > We received a question from one of our auditors about who has the > permission to do certain actions in FreeIPA itself. This is managed by > the RBAC system: you can for example configure that certain groups are > allowed to manage certain parts of FreeIPA. > > We currently only have two roles: normal users and admins. Normal users > have the default self-service permissions, and admins can do anything > within FreeIPA. However, for that last part we cannot figure out how > this is specified within FreeIPA. There is no RBAC role that gives > admins all permissions. > > Is the admins group maybe special, in that it is hardcoded to be able > to change anything within FreeIPA? Yes, the admins group is as you describe. It has pretty broad powers (but not to change anything). There are still some direct 389-ds ACIs created to grant power to the admins group. rob ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] New clients doesn't allow to use AD users with shortnames and showing the users/groups also with short names
I've been working for 1 year with a configuration that allow us to use AD users with short names for login on RHEL 6 clients and also the information on the client was showed with shortnames. Example: ssh AD_user@IDM_client1.mydomain.com PASSWORD: [AD_user@IDM_client1 ~]$ ls -la total 60 drwxr-x--- 5 AD_user AD_group 4096 Nov 21 08:53 . drwxr-xr-x. 40 root root 4096 Oct 29 09:12 .. -rw--- 1 AD_user AD_group 281 Jul 27 00:13 .bash_history -rw-r- 1 AD_user AD_group 18 Oct 8 2015 .bash_logout -rw-r- 1 AD_user AD_group 176 Oct 8 2015 .bash_profile -rw-r- 1 AD_user AD_group 124 Oct 8 2015 .bashrc [AD_user@IDM_client1 ~]$ id uid=115621(AD_user) gid=1156200014(AD_group) groups=1156200014(AD_group),10001(AD_group2),20001(IDM_group1),115620(admins)... My sssd configuration is (marked lines added for this configuration): [domain/ipa.mydomain.com] krb5_auth_timeout = 90 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = ipa.mydomain.com id_provider = ipa auth_provider = ipa access_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt ipa_hostname = IDM_client1.mydomain.com chpass_provider = ipa ipa_server = _srv_, IDM_server1.ipa.mydomain.com, IDM_server2.ipa.mydomain.com dns_discovery_domain = ipa.mydomain.com use_fully_qualified_names = true< subdomain_homedir=%o [sssd] config_file_version = 2 services = nss, sudo, pam, ssh domains = ipa.mydomain.com default_domain_suffix = AD_domain.mydomain.com < full_name_format = %1$s < [nss] filter_groups = root filter_users = root,iccsecure,tomcat,oracle reconnection_retries = 3 [pam] reconnection_retries = 3 [sudo] [ssh] But I have realized that new RHEL 6 clients are not working like that anymore. Using the SAME configuration I can not login with short name (doesn't match HABC rule because don't show IDM_groups of the user, logs at the bottom). On the console I can see that my user (short name) just have the main group of the AD, all other groups have disappeared: [AD_user@IDM_client2 ~]$ id uid=115621(AD_user) gid=1156200014(AD_group) groups=1156200014(AD_group) So I have commented the line on sssd.conf as workaround: #full_name_format = %1$s But now I have long names showed on the client server and it is very annoying: [AD_user@IDM_client2 ~]$ ls -la total 20 drwxr-x--- 3 AD_user@AD_domain.mydomain.com AD_group@AD_domain.mydomain.com 4096 Nov 21 08:20 . drwxr-xr-x 20 rootroot 4096 Mar 6 2018 .. -rw--- 1 AD_user@AD_domain.mydomain.com AD_group@AD_domain.mydomain.com 110 Nov 21 08:07 .bash_history drwx-- 2 AD_user@AD_domain.mydomain.com AD_group@AD_domain.mydomain.com 4096 Dec 14 2017 .ssh -rw--- 1 AD_user@AD_domain.mydomain.com AD_group@AD_domain.mydomain.com 138 Nov 21 08:20 .Xauthority On the servers were is working fine if I erased sssd cache and restarted sssd, then it has the problem. So should be something that has change on the latests updates and we didn't realized because we were using the cache for login. And now that we have added new servers to IDM we have discovered the problem. Can you please let me know how to configure nowadays sssd for having short names on the login for AD users and short names showed on the machine? versions I'm using:### --- IDM SERVERS - RHEL 7.5: --- ipa-common-4.5.4-10.el7_5.4.4.noarch ipa-python-compat-4.5.4-10.el7_5.4.4.noarch ipa-server-4.5.4-10.el7_5.4.4.x86_64 ipa-server-common-4.5.4-10.el7_5.4.4.noarch ipa-server-dns-4.5.4-10.el7_5.4.4.noarch ipa-server-trust-ad-4.5.4-10.el7_5.4.4.x86_64 libipa_hbac-1.16.0-19.el7_5.8.x86_64 sssd-1.16.0-19.el7_5.8.x86_64 sssd-ad-1.16.0-19.el7_5.8.x86_64 sssd-client-1.16.0-19.el7_5.8.x86_64 sssd-common-1.16.0-19.el7_5.8.x86_64 sssd-common-pac-1.16.0-19.el7_5.8.x86_64 sssd-dbus-1.16.0-19.el7_5.8.x86_64 sssd-ipa-1.16.0-19.el7_5.8.x86_64 sssd-krb5-1.16.0-19.el7_5.8.x86_64 sssd-krb5-common-1.16.0-19.el7_5.8.x86_64 sssd-ldap-1.16.0-19.el7_5.8.x86_64 sssd-proxy-1.16.0-19.el7_5.8.x86_64 sssd-tools-1.16.0-19.el7_5.8.x86_64 --- IDM CLIENTS - RHEL 6.10: --- ipa-admintools-3.0.0-51.el6.x86_64 ipa-client-3.0.0-51.el6.x86_64 ipa-python-3.0.0-51.el6.x86_64 libipa_hbac-1.13.3-60.el6.x86_64 python-iniparse-0.3.1-2.1.el6.noarch python-libipa_hbac-1.13.3-60.el6.x86_64 python-sssdconfig-1.13.3-60.el6.noarch sssd-1.13.3-60.el6.x86_64 sssd-ad-1.13.3-60.el6.x86_64 sssd-client-1.13.3-60.el6.x86_64 sssd-common-1.13.3-60.el6.x86_64 sssd-common-pac-1.13.3-60.el6.x86_64 sssd-ipa-1.13.3-60.el6.x86_64 sssd-krb5-1.13.3-60.el6.x86_64 sssd-krb5-common-1.13.3-60.el6.x86_64 sssd-ldap-1.13.3-60.el6.x86_64 sssd-proxy-1.13.3-60.el6.x86_64 sssd-tools-1.13.3-60.el6.x86_64 # LOGS # * /var/log/sssd/sssd_ipa.mydomain.com.log (debug_level = 8): ... [sssd[be[ipa.mydomain.com]]] [get_groups_dns] (0x0400): Root domain uses fully-qualified names,
[Freeipa-users] Is the admins group special?
Hi all, We received a question from one of our auditors about who has the permission to do certain actions in FreeIPA itself. This is managed by the RBAC system: you can for example configure that certain groups are allowed to manage certain parts of FreeIPA. We currently only have two roles: normal users and admins. Normal users have the default self-service permissions, and admins can do anything within FreeIPA. However, for that last part we cannot figure out how this is specified within FreeIPA. There is no RBAC role that gives admins all permissions. Is the admins group maybe special, in that it is hardcoded to be able to change anything within FreeIPA? -- Remco Kranenburg ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Migration from Test to Production
On 11/21/18 9:26 PM, Ronald Wimmer via FreeIPA-users wrote: On 21.11.18 17:40, Rob Crittenden via FreeIPA-users wrote: [..] Yes, masters are all more or less equal, the difference being whether they run optional services and there are a few roles that only one master has (CRL manager, renewal manager). I still do not have a clear picture. Is it true that any scenario starts with one master and all others are replicas? Yes, you start by installing the first master with ipa-server-install, and then create replicas with ipa-replica-install. Depending on the options you provide, you can configure (or not) additional services, such as CA, DNS, KRA etc... A given service can be present on 0 / 1 / n servers (for instance KRA is optional). For the configured services, we recommend at least 2 servers to provide redundancy. The first instance of a service is not always configured on the first master. For example, you can setup the 1st master without KRA, setup a replica without KRA and later on decide to run ipa-kra-install on the replica. In this case the KRA service is running on the replica only (and we would advise to run ipa-kra-install on another node to provide redundancy). When 2 servers provide the same set of services, they are equivalent and there is no distinction whether it was the first master or not. As Rob said, the only exception is CRL manager and renewal manager as only one node can hold this function at a given time. But this function can be migrated to another node (see [1] for the procedure). What about AD trust? Does it have to be set up for each of the new servers? https://www.freeipa.org/page/Active_Directory_trust_setup does say so: "When planning access of AD users to IPA clients, make sure to run ipa-adtrust-install on every IPA master these IPA clients will be connecting to." Then I guess it does. Can anyone confirm this? There are more explanations in this doc: [2]. A FreeIPA server can be trust controller, trust agent or standard server. The server needs to be either a trust controller or a trust agent to resolve AD users and groups. Hope this clarifies, flo [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/server-roles#server-roles-promote-to-ca [2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/windows_integration_guide/active-directory-trust#trust-controller-agent Cheers, Ron ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Can IPA-otp use together with MS Active Directory?
Hi, I'm curious that can OTP of freeipa use with MS AD, it seems it's only associated with LDAP, judging from https://www.freeipa.org/page/V4/OTP Any other work around as we are going to use AD as backend user store, and auth against VPN ( using MSchap auth type, which means it supports NThash password only) login. Thanks. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Everything getting lowercased migrating between FreeIPA instances
Hi List,
I am trying to migrate an old FreeIPA 4.3.1 server running on Ubuntu
16.04 to a new FreeIPA 4.5.4 server running on Centos 7.
I am doing the migration via the "ipa migrate-ds" command, the command
is running successfully and the users get migrated, even the custom
schema attributes come over which is nice, but everything is getting
converted to lowercase, even things like object classes, which is
causing some issues for things talking to LDAP and expecting specific
values.
A very simplistic example without going in to our custom schema is
ObjectClass: posixAccount
and after the migration
ObjectClass: posixaccount
I have tweaked /usr/lib/python2.7/site-packages/ipaserver/plugins/migration.py
as follows to try and work around this however the migration is still
lowercasing everything.
If anyone could please suggest where else in the code I should start
digging where the migration might be getting normalized into
lowercase, I would really appreciate any feedback.
--- migration.orig 2018-11-22 00:50:07.335290536 +
+++ migration.py2018-11-22 00:51:40.938290536 +
@@ -284,7 +284,7 @@
continue
api.log.debug('converting DN value %s for %s in %s' %
(value, attr, dn))
-rdnval = remote_entry[primary_key][0].lower()
+rdnval = remote_entry[primary_key][0]
entry_attrs[attr][ind] = DN((primary_key, rdnval),
container, api.env.basedn)
return dn
@@ -697,7 +697,7 @@
for name in names:
if options[name]:
options[name] = tuple(
-v.lower() for v in options[name]
+v for v in options[name]
)
else:
options[name] = tuple()
@@ -801,9 +801,9 @@
# In case if pkey attribute is in the migrated object DN
# and the original LDAP is multivalued, make sure that
# we pick the correct value (the unique one stored in DN)
-pkey = ava.value.lower()
+pkey = ava.value
else:
-pkey = entry_attrs[ldap_obj.primary_key.name][0].lower()
+pkey = entry_attrs[ldap_obj.primary_key.name][0]
if pkey in exclude:
continue
@@ -813,10 +813,10 @@
set(
config.get(
ldap_obj.object_class_config, ldap_obj.object_class
-) + [o.lower() for o in entry_attrs['objectclass']]
+) + [o for o in entry_attrs['objectclass']]
)
)
-entry_attrs[ldap_obj.primary_key.name][0] =
entry_attrs[ldap_obj.primary_key.name][0].lower()
+entry_attrs[ldap_obj.primary_key.name][0] =
entry_attrs[ldap_obj.primary_key.name][0]
callback = self.migrate_objects[ldap_obj_name]['pre_callback']
if callable(callback):
Thanks for any suggestions.
Cheers
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Can OTP use as other datasource other than LDAP?
when I deploy freeipa with build-in LDAP( 389 DS), and create user with OTP password enabled, I can integrate into freeradius with LDAP module to authenticate against Network Access Service( Switch.etc) with user's password and OTP password. My question is that, our vpn only supports MSchap authenticaion, while I want to use MS Active Directory as freeipa datastore ( Don't use 389 DS) , if OTP works as well, it's great. yet judging from https://www.freeipa.org/page/V4/OTP, it's only applicable to LDAP. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Migration from Test to Production
Ronald Wimmer via FreeIPA-users wrote: > On 19.10.18 14:15, Rob Crittenden via FreeIPA-users wrote: >> Ronald Wimmer via FreeIPA-users wrote: >>> Hi, >>> >>> we have been evaluating FreeIPA for quite a while now on our test setup >>> (1 IPA server, 1 Replica) and are planning to move towards production. >>> Can the whole setup be migrated from an ipa test to an ipa production >>> server? (the ipa 'linux.ourdomain.at' domain should stay the same) Or >>> would it be easier to use both test servers for production (and just >>> adding additional replicas)? >> >> There is no real migration mechanism between environments like you're >> looking for (e.g. test -> integration -> production). >> >> IMHO you are best off putting these systems into production and perhaps >> adding additional masters. > > How do I add new production servers? Simply issue the > "ipa-replica-install" on the new systems? (The documentation states: > "Replicas are created as clones of the initial master servers. Once a > replica is created, it is functionally identical to the master server") See the docs for instructions on creating a replica. Yes, masters are all more or less equal, the difference being whether they run optional services and there are a few roles that only one master has (CRL manager, renewal manager). > What about AD trust? Does it have to be set up for each of the new > servers? https://www.freeipa.org/page/Active_Directory_trust_setup does > say so: "When planning access of AD users to IPA clients, make sure to > run ipa-adtrust-install on every IPA master these IPA clients will be > connecting to." Then I guess it does. > Does it make sense to install CA services on each of the servers? Probably not, you just want > 1, ideally in separate locations in case of catastrophic failure. There is no reason you can't run a CA on all masters it just slightly increases replication traffic, adds some additional RAM and disk requirements and is another service to administer. rob ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
