Re: [Freeipa-users] Confused: LDAP authentication of AD users
Hi Dan > With a one-way trust from FreeIPA 4.4 to Active Directory on WinServ2012r2, I > am > trying to use FreeIPA LDAP for user authentication. > Is that supposed to work? In the way you have described it, no. AD users/groups will not be in the FreeIPA LDAP. So attempting to authenticate a Windows user by pointing an LDAP client at a FreeIPA server will fail. Installing the FreeIPA client on a Linux host and enrolling it in an IPA domain with a trust to an Active Directory domain will allow you to authenticate Windows users on the Linux host. This is done using SSSD, among other things. Regards, j -- 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] Authenticate on GNOME display manager with freeipa
Make sure you are using "reply-all" as your replies are falling off the mailing list and coming to me only. > They do have some of these lines. Assuming your common-* modules are setup correctly (which you can verify by looking at your ssh module and seeing if it uses common-* or if the sssd libraries are in there directly) at this point we'll need to go to logs. Tail your logs while attempting to do a GDM login and compare them to a tail when doing an SSH login. j > These are the contents: > > > gdm-password: > > #%PAM-1.0 > authrequisite pam_nologin.so > authrequiredpam_succeed_if.so user != root quiet_success > @include common-auth > authoptionalpam_gnome_keyring.so > @include common-account > # SELinux needs to be the first session rule. This ensures that any > # lingering context has been cleared. Without this it is possible > # that a module could execute code in the wrong domain. > session [success=ok ignore=ignore module_unknown=ignore > default=bad]pam_selinux.so close > session requiredpam_loginuid.so > # SELinux needs to intervene at login time to ensure that the process > # starts in the proper default security context. Only sessions which are > # intended to run in the user's context should be run after this. > session [success=ok ignore=ignore module_unknown=ignore > default=bad]pam_selinux.so open > session optionalpam_keyinit.so force revoke > session requiredpam_limits.so > session requiredpam_env.so readenv=1 > session requiredpam_env.so readenv=1 user_readenv=1 > envfile=/etc/default/locale > @include common-session > session optionalpam_gnome_keyring.so auto_start > @include common-password > > > gdm-autologin: > > #%PAM-1.0 > authrequisite pam_nologin.so > authrequiredpam_succeed_if.so user != root quiet_success > authrequiredpam_permit.so > @include common-account > # SELinux needs to be the first session rule. This ensures that any > # lingering context has been cleared. Without this it is possible > # that a module could execute code in the wrong domain. > session [success=ok ignore=ignore module_unknown=ignore > default=bad]pam_selinux.so close > session requiredpam_loginuid.so > # SELinux needs to intervene at login time to ensure that the process > # starts in the proper default security context. Only sessions which are > # intended to run in the user's context should be run after this. > session [success=ok ignore=ignore module_unknown=ignore > default=bad]pam_selinux.so open > session optionalpam_keyinit.so force revoke > session requiredpam_limits.so > session requiredpam_env.so readenv=1 > session requiredpam_env.so readenv=1 user_readenv=1 > envfile=/etc/default/locale > @include common-session > @include common-password > > > gdm-launch-environment: > > #%PAM-1.0 > authrequisite pam_nologin.so > authrequiredpam_permit.so > @include common-account > session optionalpam_keyinit.so force revoke > session requiredpam_limits.so > session required pam_env.so readenv=1 > session requiredpam_env.so readenv=1 user_readenv=1 > envfile=/etc/default/locale > @include common-session > @include common-password > > Thanks already! > > On 10-May-17 3:40 AM, Jason B. Nance wrote: >>> I have three files: >>> >>> /etc/pam.d/gdm-autologin >>> >>> /etc/pam.d/gdm-launch-environment >>> >>> /etc/pam.d/gdm-password >>> >>> They all have a line "@ include common-session" >>> >>> The common-session file has a line "session optional pam_sss.so" >>> >>> I don't really know what to compare to the SSH module (which I guess is >>> the /etc/pam.d/sshd file) >> Do they only have session lines and no auth, account, or password? >> -- 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] Authenticate on GNOME display manager with freeipa
> I set up my freeIPA instance and it works very well for my client > computers (Ubuntu Desktop 16.04.2 LTS), I can login via SSH using a > freeIPA managed user account. > But I cannot login to the GNOME 3 Desktop on the client. I used the > netinstall ISO image of Ubuntu. During installation, I have chose > "Ubuntu GNOME Desktop" as the only desktop. > > So my display manager is gdm3. Err, actually, I missed something here. You say you're running Ubuntu Desktop 16.04.2 LTS with Gnome 3 and GDM. However, that version/bundle ships with Unity and LightDM. I'm not saying it won't work but just trying to get clarity on your setup and letting you know you may be deviating from the "easy" path. Regards, j -- 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] Authenticate on GNOME display manager with freeipa
> But I cannot login to the GNOME 3 Desktop on the client. I used the > netinstall ISO image of Ubuntu. During installation, I have chose > "Ubuntu GNOME Desktop" as the only desktop. > > So my display manager is gdm3. It sounds as if GDM has its own PAM module that isn't configured to use SSSD. Check out /etc/pam.d/gdm or similar and see if it includes the "common-*" modules (and verify that they include the SSSD libraries in their stacks). You can compare it to the SSH module. Regards, j -- 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] GSSAPI authentication from trusted AD domain
Hi Tiemen, > To be clear, what I'm trying to do: log in from an AD account (adm.tiemen), > from > an AD host ( [ http://leon.clients.rdmedia.com/ | leon.clients.rdmedia.com ] ) > to a FreeIPA host ( [ http://neodymium.test.ams.i.rdmedia.com/ | > neodymium.test.ams.i.rdmedia.com ] ) with the same AD account. I expect to be > logged in through GSSAPI, instead I get a password prompt. I'm assuming that you are coming from a Windows client that is domain joined and logged into that Windows client with the same domain credentials that you are using to connect to the IPA-joined host. Do you also have your SSH client configured to attempt GSSAPI? It appears that you do from the logs you provided but I'm just double-checking. In my setup I've found that this feature does not work all of the time. I've not yet been able to track it down and I'm assuming it has something to do with connections to domain controllers timing out, but at this point that is speculation. So to answer your question, yes, that should work. Sorry I don't have more information for you, I guess I'm basically "me too"ing your post. Regards, j > Is this supposed to work? Did I miss something? > Below the SSH log from the FreeIPA host with LogLevel DEBUG3: > May 2 17:10:32 neodymium sshd[572]: debug3: fd 5 is not O_NONBLOCK > May 2 17:10:32 neodymium sshd[572]: debug1: Forked child 752. > May 2 17:10:32 neodymium sshd[572]: debug3: send_rexec_state: entering fd = 8 > config len 922 > May 2 17:10:32 neodymium sshd[572]: debug3: ssh_msg_send: type 0 > May 2 17:10:32 neodymium sshd[572]: debug3: send_rexec_state: done > May 2 17:10:32 neodymium sshd[752]: debug3: oom_adjust_restore > May 2 17:10:32 neodymium sshd[752]: Set /proc/self/oom_score_adj to 0 > May 2 17:10:32 neodymium sshd[752]: debug1: rexec start in 5 out 5 newsock 5 > pipe 7 sock 8 > May 2 17:10:32 neodymium sshd[752]: debug1: inetd sockets after dupping: 3, 3 > May 2 17:10:32 neodymium sshd[752]: Connection from 192.168.10.155 port 53106 > on > 192.168.50.63 port 22 > May 2 17:10:32 neodymium sshd[752]: debug1: Client protocol version 2.0; > client > software version PuTTY_KiTTY > May 2 17:10:32 neodymium sshd[752]: debug1: no match: PuTTY_KiTTY > May 2 17:10:32 neodymium sshd[752]: debug1: Enabling compatibility mode for > protocol 2.0 > May 2 17:10:32 neodymium sshd[752]: debug1: Local version string > SSH-2.0-OpenSSH_6.6.1 > May 2 17:10:32 neodymium sshd[752]: debug2: fd 3 setting O_NONBLOCK > May 2 17:10:32 neodymium sshd[752]: debug3: ssh_sandbox_init: preparing rlimit > sandbox > May 2 17:10:32 neodymium sshd[752]: debug2: Network child is on pid 753 > May 2 17:10:32 neodymium sshd[752]: debug3: preauth child monitor started > May 2 17:10:32 neodymium sshd[752]: debug1: SELinux support disabled [preauth] > May 2 17:10:32 neodymium sshd[752]: debug3: privsep user:group 74:74 [preauth] > May 2 17:10:32 neodymium sshd[752]: debug1: permanently_set_uid: 74/74 > [preauth] > May 2 17:10:32 neodymium sshd[752]: debug1: list_hostkey_types: > ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] > May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_send entering: type 42 > [preauth] > May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_receive_expect > entering: > type 43 [preauth] > May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_receive entering > [preauth] > May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_receive entering > May 2 17:10:32 neodymium sshd[752]: debug3: monitor_read: checking request 42 > May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_send entering: type 43 > May 2 17:10:32 neodymium sshd[752]: debug1: SSH2_MSG_KEXINIT sent [preauth] > May 2 17:10:32 neodymium sshd[752]: debug1: SSH2_MSG_KEXINIT received > [preauth] > May 2 17:10:32 neodymium sshd[752]: debug2: kex_parse_kexinit: > gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==, > [ mailto:curve25519-sha...@libssh.org | curve25519-sha...@libssh.org ] > ,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > [preauth] > May 2 17:10:32 neodymium sshd[752]: debug2: kex_parse_kexinit: > ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] > May 2 17:10:32 neodymium sshd[752]: debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, [ > mailto:aes128-...@openssh.com | aes128-...@openssh.com ] , [ > mailto:aes256-...@openssh.com | aes256-...@openssh.com ] , [ > mailto:chacha20-poly1...@openssh.com | chacha20-poly1...@openssh.com ] > ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, [ > mailto:rijndael-...@lysator.liu.se | rijndael-...@lysator.liu.se ] [preauth] > May 2 17:10:32 neodymium sshd[752]: debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, [ > mailto:aes128-...@openssh.com |
Re: [Freeipa-users] GSSAPI authentication from trusted AD domain
> I think I just realised that my expectation may be wrong: GSSAPI login with a > FreeIPA user logged in on an AD host to a FreeIPA host works. So is it correct > to also expect passwordless login with an AD user to a FreeIPA host? If your FreeIPA domain trusts the AD domain, then yes, you can use an AD user to login to a FreeIPA-joined Linux host from a domain-joined Windows client where you are logged into the Windows client as the AD user (assuming you have your HBACs setup to allow - if you didn't password auth wouldn't work either). Unless you've configured "default_domain_suffix" in sssd.conf the user name is "adu...@addomain.tld". If you have configured "default_domain_suffix" make sure that your user names in AD don't conflict with the user names in IPA. Regards, j > On 2 May 2017 at 17:40, Jason B. Nance < [ mailto:ja...@tresgeek.net | > ja...@tresgeek.net ] > wrote: >> Hi Tiemen, >>> To be clear, what I'm trying to do: log in from an AD account (adm.tiemen), >>> from >>> an AD host ( [ http://leon.clients.rdmedia.com/ | leon.clients.rdmedia.com >>> ] ) >>> to a FreeIPA host ( [ http://neodymium.test.ams.i.rdmedia.com/ | >>> neodymium.test.ams.i.rdmedia.com ] ) with the same AD account. I expect to >>> be >>> logged in through GSSAPI, instead I get a password prompt. >> I'm assuming that you are coming from a Windows client that is domain joined >> and >> logged into that Windows client with the same domain credentials that you are >> using to connect to the IPA-joined host. Do you also have your SSH client >> configured to attempt GSSAPI? It appears that you do from the logs you >> provided >> but I'm just double-checking. >> In my setup I've found that this feature does not work all of the time. I've >> not >> yet been able to track it down and I'm assuming it has something to do with >> connections to domain controllers timing out, but at this point that is >> speculation. >> So to answer your question, yes, that should work. Sorry I don't have more >> information for you, I guess I'm basically "me too"ing your post. >> Regards, >> j >>> Is this supposed to work? Did I miss something? >>> Below the SSH log from the FreeIPA host with LogLevel DEBUG3: >>> May 2 17:10:32 neodymium sshd[572]: debug3: fd 5 is not O_NONBLOCK >>> May 2 17:10:32 neodymium sshd[572]: debug1: Forked child 752. >>> May 2 17:10:32 neodymium sshd[572]: debug3: send_rexec_state: entering fd = >>> 8 >>> config len 922 >>> May 2 17:10:32 neodymium sshd[572]: debug3: ssh_msg_send: type 0 >>> May 2 17:10:32 neodymium sshd[572]: debug3: send_rexec_state: done >>> May 2 17:10:32 neodymium sshd[752]: debug3: oom_adjust_restore >>> May 2 17:10:32 neodymium sshd[752]: Set /proc/self/oom_score_adj to 0 >>> May 2 17:10:32 neodymium sshd[752]: debug1: rexec start in 5 out 5 newsock 5 >>> pipe 7 sock 8 >>> May 2 17:10:32 neodymium sshd[752]: debug1: inetd sockets after dupping: 3, >>> 3 >>> May 2 17:10:32 neodymium sshd[752]: Connection from 192.168.10.155 port >>> 53106 on >>> 192.168.50.63 port 22 >>> May 2 17:10:32 neodymium sshd[752]: debug1: Client protocol version 2.0; >>> client >>> software version PuTTY_KiTTY >>> May 2 17:10:32 neodymium sshd[752]: debug1: no match: PuTTY_KiTTY >>> May 2 17:10:32 neodymium sshd[752]: debug1: Enabling compatibility mode for >>> protocol 2.0 >>> May 2 17:10:32 neodymium sshd[752]: debug1: Local version string >>> SSH-2.0-OpenSSH_6.6.1 >>> May 2 17:10:32 neodymium sshd[752]: debug2: fd 3 setting O_NONBLOCK >>> May 2 17:10:32 neodymium sshd[752]: debug3: ssh_sandbox_init: preparing >>> rlimit >>> sandbox >>> May 2 17:10:32 neodymium sshd[752]: debug2: Network child is on pid 753 >>> May 2 17:10:32 neodymium sshd[752]: debug3: preauth child monitor started >>> May 2 17:10:32 neodymium sshd[752]: debug1: SELinux support disabled >>> [preauth] >>> May 2 17:10:32 neodymium sshd[752]: debug3: privsep user:group 74:74 >>> [preauth] >>> May 2 17:10:32 neodymium sshd[752]: debug1: permanently_set_uid: 74/74 >>> [preauth] >>> May 2 17:10:32 neodymium sshd[752]: debug1: list_hostkey_types: >>> ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] >>> May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_send entering: type >>> 42 >>> [preauth] >>> May 2 17:10:32 neodymium sshd[752]: debug3: mm_request_receive_expect >>> entering: >>> ty
Re: [Freeipa-users] Creating another sudo rules full
Hi Dewangga, > [root@idm ~]# ipa sudorule-show sudo_rules_rekanalar > Rule name: sudo_rules_rekanalar > Enabled: TRUE > Command category: all > RunAs User category: all > RunAs Group category: all > User Groups: rekanalar > Host Groups: rekanalarservers > Sudo Option: !authenticate > > ## Client > [user@server02-v2 ~]$ sudo -l > [sudo] password for user: The rule in your example above only matches users in the group "rekanalar" on servers in the host group "rekanalarservers". Is the user "user" in your example in that group and is the host "server02-v2" in your example in that host group? Regards, j -- 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] creating an LDAP bind user
Hi Chris, > # remoteu, sysaccounts, etc, example.com > dn: uid=remoteu,cn=sysaccounts,cn=etc,dc=example,dc=com > objectClass: account > objectClass: simplesecurityobject > objectClass: top > uid: remoteu > userPassword:: [hash value] > > This new user is unable to run LDAP searches though: > ldapsearch -D 'cn=remoteu' -W -H ldap://ipa01.example.com -x uid=remoteu > Enter LDAP Password: > ldap_bind: Invalid credentials (49) Your DN (-D) is incorrect in your ldapsearch call. It needs to match the part after the "dn:" string you provided in your query of the user above (uid=remoteu,cn=sysaccounts,cn=etc,dc=example,dc=com). In some cases you can shorten the DN but only if your suffix/basedn is set correctly for the client making the call. Regards, j -- 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] What's the proper format for an automember serverhostname rule?
Hi Greg, > I'm trying to set up a rule based on server hostname. So for example, 10.100.* > would be put into the 'developers' hostgroup. I can't figure out the proper > format of the inclusive regex. I've tried: I believe that your regex needs to match the host name, not the IP address. Unless your host name is 10.100. I don't think that will match. The regex for "anything" is ".*". I think that the pcre syntax is what is used. Regards, j -- 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] Problem automounting home shares
Hi Ronald, > Some details regarding my setup: I have a CentOS 7.3 machine acting as > an NFS server. It is a host within my IPA domain and enrolled as an IPA > client. > > [root@ipanfs ~]# cat /etc/exports > > /homeshare*(rw,sec=krb5:krb5i:krb5p) This isn't related to your issue but you have your exports setup as if you're using NFSv3. They will still work, of course, but you aren't taking advantage of the pseudo filesystem. For example, you could have something such as: /etc/exports: /export *(rw,sync,crossmnt,no_subtree_check,sec=krb5:krb5i:krb5p,fsid=0) Then: mkdir -p /export/homeshare mount -o bind /homeshare /export/homeshare (or even /home if you have autofs disabled on your NFS server) It may be worth some Googling to see if you care about the benefits, but again, it isn't why you are having issues. > I defined a automount location called ipauserhome. In this location I > have a map called auto.home with this content: > > * -fstype=nfs4,rw,sec=krb5 ipanfs.linux.oebb.at:/homeshare/& > > On an ipa client I just did "ipa-client-automount > --location=ipauserhome" and "authconfig --enablemkhomedir --update". You cannot use indirect mounting and enablemkhomedir at the same time. Indirect mounts require that the directory you are attempting to mount already exists on the NFS server and that you let autofs fully manage the "parent" directory on the client machine. In this case, no one other than autofs can create directories in the top-level of /home on your clients (/home/ is a different story). So you either need to pre-create the home directories on your NFS server (including ownership, permissions, and any "skel" stuff you want in there like a default .bashrc) or you need to direct mount /home altogether and lose the benefits of indirect mounting (which may not matter to you). > but for some reason it works not as expected. SELinux is set to > permissive on both NFS server and the ipa client. Nevertheless, I get a > suspicious message in /var/log/messages: In permissive mode SELinux messages are still displayed in the logs but not enforced. This allows you to troubleshoot SELinux-related issues. To use NFS home directories with NFS you need to run the following on the client systems: setsebool -P use_nfs_home_dirs on Regards, j -- 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] Problem automounting home shares
>> You cannot use indirect mounting and enablemkhomedir at the same time. >> Indirect >> mounts require that the directory you are attempting to mount already exists >> on >> the NFS server and that you let autofs fully manage the "parent" directory on >> the client machine. In this case, no one other than autofs can create >> directories in the top-level of /home on your clients (/home/ is a >> different story). >> >> So you either need to pre-create the home directories on your NFS server >> (including ownership, permissions, and any "skel" stuff you want in there >> like >> a default .bashrc) or you need to direct mount /home altogether and lose the >> benefits of indirect mounting (which may not matter to you). >> [...] > > So this means I can either use /home mounted as NFS share conventionally > (without autofs) in combination with mkhomedir or use autofs magic with > pre-created directories. You can still use autofs and mkhomdir, just use a direct mount for /home instead of indirect mounts. In other words, mount "/home" entirely vs. "/home/" individually. Regards, j -- 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] Trying To Debug AD Trust Quirks
Hello, I'm using AD trusts with FreeIPA 4.4.0 and am having a heck of a time with strange behavior. Some examples include: - Trust user's home directory sporadically getting set to '/' instead of /home/domain/user - Trust user losing HBAC privileges (granted via group membership) - Trust user losing sudo privileges (granted via group membership) - OS logging that trust user's account has expired when it hasn't I'm currently unable to predict/reproduce occurrences of these issues. I can say that they aren't tied to a specific user or host. For example, a user will login to a host without any issues and then later that same user's home directory (as reported by getent) will suddenly be set to / instead of /home/... My first step, of course, is to gather logs. Should I be focusing on the SSSD on the client or on the IPA servers? I'm not entirely clear how/where lots of this data get assigned/queried. My other question is if there is a way to pin down a client to [temporarily] use a specific IPA server and specific AD server (even if it means a firewall rule that only allows the host to communicate with one IPA and one AD host). Thanks, j -- 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] Authenticating windows users
> Thanks Jason, but those documents need AD as the primary authenticator. This > is > not the case for us. I think you need to read them a bit closer. Very first line of first link says: "This article describes direct integration between FreeIPA and Windows machine, i.e. without involving Active Directory server." > On Thu, Mar 23, 2017 at 11:46 AM, Jason B. Nance < [ > mailto:ja...@tresgeek.net | > ja...@tresgeek.net ] > wrote: >>> We are primarily linux/osx shop and we currently have FreeIPA/IDM (ver 4.2) >>> as >>> our master. I will need to add a handful of windows machines and been >>> trying to >>> figure out how to authenticate our windows users with FreeIPA/IDM. Is this >>> even >>> possible? I know Global Catalogs may not happen anytime soon (sad face). I'm >>> open to -all- ideas, even if it is a paid solution (not sure if centrify and >>> the likes can sync up to FreeIPA/IDM). >> I would start here: >> [ https://www.freeipa.org/page/Windows_authentication_against_FreeIPA | >> https://www.freeipa.org/page/Windows_authentication_against_FreeIPA ] >> [ >> https://www.freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_(Windows/Linux)_-_Step_by_step >> | >> https://www.freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_(Windows/Linux)_-_Step_by_step >> ] -- 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] Authenticating windows users
> We are primarily linux/osx shop and we currently have FreeIPA/IDM (ver 4.2) as > our master. I will need to add a handful of windows machines and been trying > to > figure out how to authenticate our windows users with FreeIPA/IDM. Is this > even > possible? I know Global Catalogs may not happen anytime soon (sad face). I'm > open to -all- ideas, even if it is a paid solution (not sure if centrify and > the likes can sync up to FreeIPA/IDM). I would start here: https://www.freeipa.org/page/Windows_authentication_against_FreeIPA https://www.freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_(Windows/Linux)_-_Step_by_step -- 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] [solved] Re: GSSAPI for second hop (SSH)
>I have a FreeIPA 4.4.0 setup with Active Directory trusts. Users >connecting to >Linux servers from their domain-joined workstations are not required to >enter a >password for the first connection. However, if they attempt to ssh to a >second >Linux machine from the first they are being prompted for a password. > >I've tried the following /etc/ssh/ssh_config options: > >GSSAPIDelegateCredentials yes >GSSAPIKeyExchange yes >GSSAPIRenewalForcesRekey yes >GSSAPITrustDns yes > >And the following /etc/ssh/sshd_config options: > >GSSAPIAuthentication yes >GSSAPIKeyExchange yes >GSSAPIStoreCredentialsOnRekey yes > >Am I missing a step/configuration? >>> They need to allow delegation on the machine where their first hop starts, not only on your jump server. >>> >>>Both the first hop and subsequent servers have those settings. > >> I'm not talking about servers. It starts with the client machines. >> If server never got delegated credentials, how could it be a client that >> delegates them further? That original client has to allow delegation >> in first place. > > Do you know how I can validate that is working (such as, will something show > up > in a klist)? I'm using PuTTY 0.67 as my Windows ssh client and have the > "Allow > GSSAPI credential delegation" box checked, but some quick Googling is > suggesting that may not be enough. Okay, I missed something REALLY basic. :-( In my SSH client configuration I didn't have "GSSAPIAuthentication yes", and the default is "no". The key exchange doesn't work, but gssapi-with-mic does. Here's an excerpt from "ssh -vvv": debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-keyex debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-keyex debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug2: we did not send a packet, disable method debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Delegating credentials debug1: Delegating credentials debug1: Authentication succeeded (gssapi-with-mic). Authenticated to sl1mmgplsat0001 (via proxy). -- 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] GSSAPI for second hop (SSH)
I have a FreeIPA 4.4.0 setup with Active Directory trusts. Users connecting to Linux servers from their domain-joined workstations are not required to enter a password for the first connection. However, if they attempt to ssh to a second Linux machine from the first they are being prompted for a password. I've tried the following /etc/ssh/ssh_config options: GSSAPIDelegateCredentials yes GSSAPIKeyExchange yes GSSAPIRenewalForcesRekey yes GSSAPITrustDns yes And the following /etc/ssh/sshd_config options: GSSAPIAuthentication yes GSSAPIKeyExchange yes GSSAPIStoreCredentialsOnRekey yes Am I missing a step/configuration? >> >>> They need to allow delegation on the machine where their first hop >>> starts, not only on your jump server. >> >>Both the first hop and subsequent servers have those settings. > I'm not talking about servers. It starts with the client machines. > If server never got delegated credentials, how could it be a client that > delegates them further? That original client has to allow delegation > in first place. Do you know how I can validate that is working (such as, will something show up in a klist)? I'm using PuTTY 0.67 as my Windows ssh client and have the "Allow GSSAPI credential delegation" box checked, but some quick Googling is suggesting that may not be enough. Thanks for the insight. j -- 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] GSSAPI for second hop (SSH)
>> I have a FreeIPA 4.4.0 setup with Active Directory trusts. Users >> connecting to Linux servers from their domain-joined workstations are >> not required to enter a password for the first connection. However, >> if they attempt to ssh to a second Linux machine from the first they >> are being prompted for a password. > > What is the output if they klist on the first machine they SSH to? [jna...@centric.com@sl1aosplmgt0001 ~]$ klist Ticket cache: KEYRING:persistent:255985:krb_ccache_TuVdBrp Default principal: jna...@centric.com Valid starting Expires Service principal 03/03/2017 11:55:16 03/03/2017 21:47:34 krbtgt/ipa.gen.z...@centric.com renew until 03/04/2017 11:47:33 03/03/2017 11:47:34 03/03/2017 21:47:34 krbtgt/centric@centric.com renew until 03/04/2017 11:47:33 centric.com is the AD domain that ipa.gen.zone trusts. -- 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] GSSAPI for second hop (SSH)
>>I have a FreeIPA 4.4.0 setup with Active Directory trusts. Users connecting >>to >>Linux servers from their domain-joined workstations are not required to enter >>a >>password for the first connection. However, if they attempt to ssh to a >>second >>Linux machine from the first they are being prompted for a password. >> >>I've tried the following /etc/ssh/ssh_config options: >> >>GSSAPIDelegateCredentials yes >>GSSAPIKeyExchange yes >>GSSAPIRenewalForcesRekey yes >>GSSAPITrustDns yes >> >>And the following /etc/ssh/sshd_config options: >> >>GSSAPIAuthentication yes >>GSSAPIKeyExchange yes >>GSSAPIStoreCredentialsOnRekey yes >> >>Am I missing a step/configuration? > They need to allow delegation on the machine where their first hop > starts, not only on your jump server. Both the first hop and subsequent servers have those settings. -- 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] GSSAPI for second hop (SSH)
Hello, I have a FreeIPA 4.4.0 setup with Active Directory trusts. Users connecting to Linux servers from their domain-joined workstations are not required to enter a password for the first connection. However, if they attempt to ssh to a second Linux machine from the first they are being prompted for a password. I've tried the following /etc/ssh/ssh_config options: GSSAPIDelegateCredentials yes GSSAPIKeyExchange yes GSSAPIRenewalForcesRekey yes GSSAPITrustDns yes And the following /etc/ssh/sshd_config options: GSSAPIAuthentication yes GSSAPIKeyExchange yes GSSAPIStoreCredentialsOnRekey yes Am I missing a step/configuration? Thanks, j -- 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] AD Sites and Trusts
Hello, I was wondering if this thread regarding AD trusts and sites is still correct: https://www.redhat.com/archives/freeipa-users/2015-December/msg00214.html (no way to make use of AD sites) If so, is there already an RFE for this that I can vote for and track? Thanks, j -- 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] ldapsearch for AD users
> I realized I had made one more change. I setup the FreeIPA server again and > this > time I added the --enable-compat with my /usr/sbin/ipa-adtrust-install > command. Is it safe to re-run ipa-adtrust-install? I have existing trusts in place. Thanks, j -- 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] ldapsearch for AD users
> For example, for user that would be (&(objectClass=posixAccount)(uid=%s)) > where %s is ad_u...@server.com according to your example. > > This is what would be intercepted and queried through SSSD. > > For example: > > $ ldapsearch -Y GSSAPI -b cn=compat,dc=xs,dc=ipa,dc=cool > '(&(objectClass=posixAccount)(uid=u...@ad.ipa.cool))' > SASL/GSSAPI authentication started > SASL username: ad...@xs.ipa.cool > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base
Re: [Freeipa-users] sudo NOPASSWD for a single command
> We have a script stored on a particular server in our realm that executes a > number of non-privileged commands and are wanting to add /sbin/vgs command. > The > script uses SSH to then execute the same set of commands on all the servers in > the realm. > The owner of the script is in the administrator group and there are sudoer > commands for the administrator group in general. We need to place a rule for > this one command for either this group or the script owner to run NOPASSWD. > Where and how would I specify that in the IPA admin console? Have you tried creating your command in IPA as "NOPASSWD: /sbin/vgs" (Policy -> Sudo -> Sudo Commands)? -- 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] ldapsearch for AD users
> There is none. Compat tree is built with RFC2307 queries in mind. > RFC2307 clients issue a request with a specific user or group name and > that triggers lookup of AD user/group through SSSD and insertion into > the compat tree. A part of the trigger is how LDAP filter is built (see > RFC for those). If your software does not use the same filter, you > wouldn't get a response. Are you saying that there is an LDAP query you can use to retrieve the UID/GID of a user/group that is known via an AD trust as long as the filter is correct? I ran into this same situation (with a storage appliance) and thought that the problem was that the UIDs/GIDs were calculated but never stored, but I hadn't stopped to think about how whether sssd (on the local machine) retrieves them from FreeIPA or does the calculation. -- 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] DM Password Reset in 4.4.0
Hello All, I have managed to lose the Directory Manager password for my FreeIPA 4.4.0 instance. I've found the following documentation: http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassword.html And: http://www.freeipa.org/page/Howto/Change_Directory_Manager_Password I'm confused as to whether I need to follow the procedure in the second link because of the following note on the page: The following procedure is only applicable to FreeIPA 3.2.1 or older. Since FreeIPA 3.2.2 (and ticket #3594), the procedure is automated as a part of preparing a replica info file by using ipa-replica-prepare The wording of that seems to indicate that it is a copy/paste from a different doc on how to setup PKI (due to the reference to ipa-replica-prepare). Could someone shed some light on the proper way to go about resetting the Directory Manager password in 4.4.0? Thanks, j -- 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] Is WinSync A Bad Choice?
>>> - User/group management in general becomes largely a command-line operation >> > (such as mapping groups so they can be used in HBAC and sudo rules) >> While this is a nice-to-have, it isn't a deal breaker. > This definitely exists in WebUI? Unless you mean something I don't understand. > Define groups: > Identity->User Groups (second tab) In my setup (FreeIPA 4.4.0 on CentOS 7) I don't see external users (users that are known via the trust with AD) under the "Users" tab. There is limited visibility / management of external groups and membership, but nothing that displays a list of available users/groups in AD when attempting to create/modify a user/group. > Define user mappings: > IPA Server -> ID Views -> Default Trust View By "mapping" I meant adding an AD group to a FreeIPA group (which can be used for HBAC/sudo) so that AD membership is known by IPA when applying the HBAC/sudo rules. For example: ipa group-add \ --desc="lab.gen.zone 'Domain Admins' external map" \ lgz_map_domain_admins \ --external ipa group-add \ --desc="lab.gen.zone 'Domain Admins' POSIX" \ lgz_domain_admins ipa group-add-member \ lgz_map_domain_admins \ --external 'LAB\Domain Admins' ipa group-add-member \ lgz_domain_admins \ --groups lgz_map_domain_admins -- 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] Is WinSync A Bad Choice?
>> - Users can't login to a Linux box using just "username" (user@ad.domain >> is >> used) > > In the current version you can use the 'default_domain_suffix' option in > sssd.conf on the clients. In RHEL-7.4 we are looking into making this > limitation go away. Thank you very much, Jakub. That is helpful information! Are you saying that there will basically be a domain search order or something for users that login without specifying a domain? Back to the community as a whole, regarding these other items: >- Since AD trust users don't show up in FreeIPA web UI users can't login > to manage their own SSH keys After doing some additional thinking/researching I realized that SSH keys become largely irrelevant because of GSSAPI (Dmitri Pal posed this question in this thread: https://www.redhat.com/archives/freeipa-users/2013-September/msg00290.html). >- User/group management in general becomes largely a command-line > operation (such as mapping groups so they can be used in HBAC and sudo rules) While this is a nice-to-have, it isn't a deal breaker. I have another question. Can additional authentication requirements (such as 2FA) be imposed on users from a trust via IPA? Thanks, j -- 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] Is WinSync A Bad Choice?
Hello everyone, I'm about to deploy a fresh IPA domain that needs to integrate with Active Directory. In my lab environment I've setup a trust with AD and the following items are driving me away from using the trust: - Users can't login to a Linux box using just "username" (user@ad.domain is used) - Since AD trust users don't show up in FreeIPA web UI users can't login to manage their own SSH keys - User/group management in general becomes largely a command-line operation (such as mapping groups so they can be used in HBAC and sudo rules) First, if any of the above is incorrect or there are workarounds I am very much open to discussion. I'm considering using WinSync+PassSync so that users and groups appear as "real" IPA objects to be managed normally. Given that an entire tool has been written to migrate away from WinSync to AD trusts and language in the RH documentation suggesting to only use WinSync if you have to I'm wondering what issues I'm not considering and if I could be leading toward a world of hurt. Guidance in this area is appreciated. Thanks, j -- 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] Lookups Failing With AD Forwarder (and DNSSEC)
>> I have a pair of FreeIPA 4.4.0 servers setup whose forwarders are each set >> to an >> Active Directory domain controller. When a client attempts to lookup any DNS >> record other than those to which FreeIPA is authoritative the client reports >> NXDOMAIN and the FreeIPA server has the following in its logs: >> >> (first lookup) >> Jan 04 16:05:21 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: error >> (no >> valid RRSIG) resolving 'zone/DS/IN': 10.48.8.18#53 >> Jan 04 16:05:21 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: error >> (no >> valid DS) resolving 'sl1mmgpwtdc0001.tkc.gen.zone/A/IN': 10.48.8.18#53 >> >> (subsequent lookups) >> Jan 04 16:10:57 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: >> validating >> @0x7f7a40983ea0: sl1mmgpwtdc0001.tkc.gen.zone A: bad cache hit (zone/DS) >> Jan 04 16:10:57 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: error >> (broken trust chain) resolving 'sl1mmgpwtdc0001.tkc.gen.zone/A/IN': >> 10.48.8.18#53 >> >> In my case, ipa.tkc.gen.zone is served by FreeIPA and tkc.gen.zone is served >> by >> AD (as is gen.zone). 10.48.8.18 is an AD domain controller for tkc.gen.zone >> (and the forwarder the FreeIPA servers are pointed at). >> >> I've tried "rndc flush" and "rndc flushname ." on the FreeIPA boxes. We've >> tried both NSEC3 and NSEC. >> >> Anyone have guidance as to what may be going on? >> >> Thanks, >> >> j >> > > you use non-existent TLD domain or TLD domain doesn't have DS record of > your zone, so this is expected behavior for DNSSEC considered as attack. > You have to disable DNSSEC validation on all IPA DNS servers in > /etc/named.conf in first case or fix incorrect/missing DS record in > second case. > > The 'zone.' is registered TLD, so if you own it you have probably > missing DS record in path, thus broken trust chain. > If you don't own the TLD, you shouldn't use it at all. Hi Martin, Thank you for the reply, and sorry for the delay in response. My employer owns the "gen.zone" domain. It is used internally only, and served by an Active Directory domain controller. It appears, though, that our registrar does not support DNSSEC for .zone domains even though the .zone TLD in general does support DNSSEC. :-\ j -- 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] Weird single user problem
Hi Matthew, > Where should I start looking? I would start by tailing the logs on the destination host while the user attempts to login with the account that isn't working. On an EL 7 host you can use 'journalctl -f', on EL 6 and older you can use 'tail -F /var/log/messages /var/log/secure'. Are you certain this was just a forgotten password (in other words, was the user ever able to login to this particular machine)? Do you use any HBAC rules in your environment? Regards, j -- 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] Lookups Failing With AD Forwarder (and DNSSEC)
Hello everyone, I have a pair of FreeIPA 4.4.0 servers setup whose forwarders are each set to an Active Directory domain controller. When a client attempts to lookup any DNS record other than those to which FreeIPA is authoritative the client reports NXDOMAIN and the FreeIPA server has the following in its logs: (first lookup) Jan 04 16:05:21 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: error (no valid RRSIG) resolving 'zone/DS/IN': 10.48.8.18#53 Jan 04 16:05:21 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: error (no valid DS) resolving 'sl1mmgpwtdc0001.tkc.gen.zone/A/IN': 10.48.8.18#53 (subsequent lookups) Jan 04 16:10:57 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: validating @0x7f7a40983ea0: sl1mmgpwtdc0001.tkc.gen.zone A: bad cache hit (zone/DS) Jan 04 16:10:57 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: error (broken trust chain) resolving 'sl1mmgpwtdc0001.tkc.gen.zone/A/IN': 10.48.8.18#53 In my case, ipa.tkc.gen.zone is served by FreeIPA and tkc.gen.zone is served by AD (as is gen.zone). 10.48.8.18 is an AD domain controller for tkc.gen.zone (and the forwarder the FreeIPA servers are pointed at). I've tried "rndc flush" and "rndc flushname ." on the FreeIPA boxes. We've tried both NSEC3 and NSEC. Anyone have guidance as to what may be going on? Thanks, j -- 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
