[Freeipa-users] FreeIPA, Netgroup and access.conf

[Yves Degauquier]

Yes getent netgroup <netgroupname> give me the list of servers.

Can't understant what is going wrong...

Yves

On 02/06/15 13:38, freeipa-users-request at redhat.com wrote:
> Send Freeipa-users mailing list submissions to
> 	freeipa-users at redhat.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.redhat.com/mailman/listinfo/freeipa-users
> or, via email, send a message with subject or body 'help' to
> 	freeipa-users-request at redhat.com
>
> You can reach the person managing the list at
> 	freeipa-users-owner at redhat.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Freeipa-users digest..."
>
>
> Today's Topics:
>
>     1. Re: FreeIPA, Netgroup and access.conf (Jakub Hrozek)
>     2. Re: login delay with sssd (Jakub Hrozek)
>     3. Re: Copy attributes to compat tree (Jakub Hrozek)
>     4. Re: AD user password change via ssh login (Alexander Frolushkin)
>     5. Re: Copy attributes to compat tree (Vangass)
>     6. deny to change shell (Ivars Strazdi??)
>     7. Re: vSphere and freeIPA (Sam)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 2 Jun 2015 12:10:19 +0200
> From: Jakub Hrozek <jhrozek at redhat.com>
> To: freeipa-users at redhat.com
> Subject: Re: [Freeipa-users] FreeIPA, Netgroup and access.conf
> Message-ID: <20150602101019.GL2805 at hendrix>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Jun 02, 2015 at 11:11:56AM +0200, Yves Degauquier wrote:
>> Hi,
>>
>> I have a FreeIPA server in place with netgroup in order to limit access to
>> some users only to some hosts (by environment).
>>
>> It works fine on AIX clients.
>>
>> But now I try to do the same with Linux.
>>
>> I register the client in the server, without any problem, all users from
>> FreeIPA can login in the Linux boxes.
>>
>> I activate now pam_access and configure the /etc/security/access.conf to
>> allow local root user and users from netgroup.
>>
>> But my users in the netgroup can't login... If in place of the netgroup I
>> put the name of the users, the users defined can login...
>>
>> But this is not anymore a centally managed user...
>>
>> Any idea of what the problem could be?
>>
>> Thanks in advance for your help.
> Does getent netgr report the host as a member of the netgroup?
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 2 Jun 2015 12:11:57 +0200
> From: Jakub Hrozek <jhrozek at redhat.com>
> To: freeipa-users at redhat.com
> Subject: Re: [Freeipa-users] login delay with sssd
> Message-ID: <20150602101157.GM2805 at hendrix>
> Content-Type: text/plain; charset=utf-8
>
> On Tue, Jun 02, 2015 at 10:28:29AM +0100, Ivars Strazdi?? wrote:
>>
>>
>> Ar laipniem sveicieniem,
>> Ivars Strazdi??
>>
>>> On 2. j?n. 2015, at 07:21, Lukas Slebodnik <lslebodn at redhat.com> wrote:
>>>
>>> How many groups does problematic user have?
>> I can call any user problematic, because all have login delays.
>> sitaadmin user, being able to to login via ssh, probably has most groups - 4. Doesn?t seem too many, does it?
>>
>> siteadmin at mail:~$ id
>> uid=9268000XX(siteadmin) gid=9268000XX(siteadmin) groups=9268000XX(siteadmin),92680000Y(vpnusers),92680000Z(mailusers),92680000W(scanned) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
>>
>> I have sssh-1.12.2 installed as per Centos 7.1.
>> I will have to wait until 1.12.4 or 5 is coming down the pipe with Centos updates.
> We plan on 7.1.z update, but with different bugzillas.
>
> Then we plan on putting 1.13 to 7.2
>
>> Hopefully that will resolve or mitigate the issue.
>> I cannot create mess by putting Fedora updates into Centos, not sure if that's even possible.
> Lukas keeps the 1.12 branch builds in his COPR repo, maybe those would
> be easier to test for you?
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 2 Jun 2015 12:12:38 +0200
> From: Jakub Hrozek <jhrozek at redhat.com>
> To: freeipa-users at redhat.com
> Subject: Re: [Freeipa-users] Copy attributes to compat tree
> Message-ID: <20150602101238.GN2805 at hendrix>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Jun 02, 2015 at 11:45:44AM +0200, Vangass wrote:
>> Hi,
>>
>> Is it possible to copy all of "memberOf" users attributes from
>> cn=users,cn=accounts,dc=example,dc=com
>> to cn=users,cn=compat,dc=example,dc=com?
>>
>> If yes, how can I do this?
> No, the compat tree uses a different schema.
>
> Why do you need this?
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 2 Jun 2015 10:24:35 +0000
> From: Alexander Frolushkin <Alexander.Frolushkin at megafon.ru>
> To: Jakub Hrozek <jhrozek at redhat.com>, "freeipa-users at redhat.com"
> 	<freeipa-users at redhat.com>
> Subject: Re: [Freeipa-users] AD user password change via ssh login
> Message-ID: <9ec27b853e134e21b1c7bcf17fc39253 at sib-ums03.Megafon.ru>
> Content-Type: text/plain; charset="utf-8"
>
> Hello Jakub!
> Thank you for respond, I'll comment in text
>
> -----Original Message-----
> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Jakub Hrozek
> Sent: Tuesday, June 02, 2015 1:24 PM
> To: freeipa-users at redhat.com
> Subject: Re: [Freeipa-users] AD user password change via ssh login
>
> On Tue, Jun 02, 2015 at 06:21:59AM +0000, Alexander Frolushkin wrote:
>>> Hello.
>>> Maybe this is a little off topic, sorry if so.
>>> Faced a strange behavior of server when trying to login a newly created user from AD, which have a password must be changed on first login.
>>> Using this user to login via ssh to server feeds to ssh session termination without any messages regarding to password expire. If I do kinit this user on same server, it does request password change.
>>>
>>> In secure log:
>>> Jun  2 12:18:15 server sshd[9830]: pam_unix(sshd:auth): authentication
>>> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.10.100.1
>>> user=sdemiden at ad.com Jun  2 12:18:15 server sshd[9830]:
>>> pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0
>>> tty=ssh ruser= rhost=10.10.100.1 user=sdemiden at ad.com Jun  2 12:18:15
>>> server sshd[9830]: pam_sss(sshd:auth): received for user
>>> sdemiden at ad.com: 12 (Authentication token is no longer valid; new one
>>> required) Jun  2 12:18:15 server sshd[9830]: pam_sss(sshd:account):
>>> Access denied for user sdemiden at ad.com: 6 (Permission denied)
>> It would be interesting to see the logs, because you're being denied in the account phase, where I would expect the user being either expired, locked or denied by HBAC rules.
> Do you mean sssd logs in debug?
>
>> Does the login work with such user if you (temporarily!!) set access_provider=permit ?
> Yes, it does. With this it asks to change password as usual.
>
>>> Jun  2 12:18:15 server sshd[9830]: Failed password for sdemiden at ad.com
>>> from 10.10.100.1 port 41859 ssh2 Jun  2 12:18:15 server sshd[9831]:
>>> fatal: Access denied for user sdemiden at ad.com by PAM account
>>> configuration
>>>
>>> If I further change the password of user manually from Windows, login works as expected.
>>>
>>> WBR,
>>> Alexander Frolushkin
>>> Cell +79232508764
>>> Work +79232507764
> ________________________________
>
> ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????.
>
> The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof.
>
> (c)20mf50
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 2 Jun 2015 12:58:21 +0200
> From: Vangass <vangass at gazeta.pl>
> To: Freeipa-users <freeipa-users at redhat.com>
> Subject: Re: [Freeipa-users] Copy attributes to compat tree
> Message-ID:
> 	<CAL0HfVEH7RCkmrNX8KgjgMK20RrrkNyqDt7CKvcJpEYC6rCG0Q at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Well, I needed to set IPA to authenticate HP iLO users via LDAP. But iLO
> asks for cn not uid. So I change in compat tree uid to cn and that's ok.
> But also, I have to have memberOf attributes with user groups and they are
> available on standard schema not the compat.
> I managed to modify user entry in compat tree and add memberOf attribute
> with proper group but I want to do it automatically.
>
> PS. I also have tacacs and other devices authenticated with IPA and they
> works just fine.
>
> 2015-06-02 12:12 GMT+02:00 Jakub Hrozek <jhrozek at redhat.com>:
>
>> On Tue, Jun 02, 2015 at 11:45:44AM +0200, Vangass wrote:
>>> Hi,
>>>
>>> Is it possible to copy all of "memberOf" users attributes from
>>> cn=users,cn=accounts,dc=example,dc=com
>>> to cn=users,cn=compat,dc=example,dc=com?
>>>
>>> If yes, how can I do this?
>> No, the compat tree uses a different schema.
>>
>> Why do you need 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
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://www.redhat.com/archives/freeipa-users/attachments/20150602/f873933f/attachment.html>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 2 Jun 2015 12:26:06 +0100
> From: Ivars Strazdi?? <ivars.strazdins at sets.lv>
> To: freeipa-users at redhat.com
> Subject: [Freeipa-users] deny to change shell
> Message-ID: <DB06619D-7768-4522-BC7D-2E1F6B6607E8 at sets.lv>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
> just another basic question, I am sorry to spam the list.
> Noticed that regular users can change their login shell in account settings.
> Is it possible to lock login shell property for a regular user?
> For a unix system, using standard PAM authentication, use of chsh command can be restricted.
> I could not find anything regarding this in IPA manual.
>
> With kind regards,
> Ivars
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://www.redhat.com/archives/freeipa-users/attachments/20150602/8c241131/attachment.html>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 02 Jun 2015 11:37:58 +0000
> From: "Sam" <sam at zy.io>
> To: "Alexander Bokovoy" <abokovoy at redhat.com>,
> 	freeipa-users at redhat.com
> Subject: Re: [Freeipa-users] vSphere and freeIPA
> Message-ID: <47a90ebcf35988a8cb4b5956986a8834 at webmail.zy.io>
> Content-Type: text/plain; charset="utf-8"
>
> 2 June 2015 08:55, "Alexander Bokovoy" <abokovoy at redhat.com> wrote:
>> On Tue, 02 Jun 2015, Martin Kosek wrote:
>>
>>> CCing Nalin and Alexander. This sounds like the slapi-nis >configuration for generating
>>> uniqueMember attribute does not work with >multi-valued "member" attribute:
>>>
>>> schema-compat-entry-attribute: >uniqueMember=%mregsub("%{member}","^(.*)accounts(.*)","%1compat%2")
>> No, this should work just fine. The original wiki page had just
>> %regsub() which is indeed a single element replacement. %mregsub()
>> processes multiple possible expression matching.
>>
>> I just tried myself:
>> # ldapmodify -x -D "cn=Directory Manager" -f vsphere.ldif -W Enter LDAP Password: modifying entry
>> "cn=groups,cn=Schema Compatibility,cn=plugins,cn=config"
>>
>> modifying entry "cn=users,cn=Schema Compatibility,cn=plugins,cn=config"
>>
>> # ipa permission-mod "System: Read User Compat Tree" --includedattrs sn
>> ---------------------------------------------------
>> Modified permission "System: Read User Compat Tree"
>> ---------------------------------------------------
>> Permission name: System: Read User Compat Tree
>> Granted rights: read, compare, search
>> Effective attributes: cn, createtimestamp, entryusn, gecos, gidnumber,
>> homedirectory, loginshell, modifytimestamp, objectclass, sn, uid,
>> uidnumber
>> Included attributes: sn
>> Default attributes: cn, objectclass, loginshell, uidnumber, gidnumber,
>> gecos, homedirectory, uid
>> Bind rule type: anonymous
>> Subtree: dc=t,dc=vda,dc=li
>> Target DN: cn=users,cn=compat,dc=t,dc=vda,dc=li
>> # ipa permission-mod "System: Read Group Compat Tree" --includedattrs uniquemember
>> ----------------------------------------------------
>> Modified permission "System: Read Group Compat Tree"
>> ----------------------------------------------------
>> Permission name: System: Read Group Compat Tree
>> Granted rights: read, compare, search
>> Effective attributes: cn, createtimestamp, entryusn, gidnumber,
>> memberuid, modifytimestamp, objectclass, uniquemember
>> Included attributes: uniquemember
>> Default attributes: objectclass, memberuid, gidnumber, cn
>> Bind rule type: anonymous
>> Subtree: dc=t,dc=vda,dc=li
>> Target DN: cn=groups,cn=compat,dc=t,dc=vda,dc=li
>> # ipa group-add foo-bar-zed
>> -------------------------
>> Added group "foo-bar-zed"
>> -------------------------
>> Group name: foo-bar-zed
>> GID: 895600028
>> # ipa user-add bar
>> First name: bar
>> Last name: bar
>> ----------------
>> Added user "bar"
>> ----------------
>> User login: bar
>> First name: bar
>> Last name: bar
>> Full name: bar bar
>> Display name: bar bar
>> Initials: bb
>> Home directory: /home/bar
>> GECOS: bar bar
>> Login shell: /bin/sh
>> Kerberos principal: bar at T.VDA.LI
>> Email address: bar at t.vda.li
>> UID: 895600029
>> GID: 895600029
>> Password: False
>> Member of groups: ipausers
>> Kerberos keys available: False
>> # ipa user-add foo
>> First name: foo
>> Last name: foo
>> ----------------
>> Added user "foo"
>> ----------------
>> User login: foo
>> First name: foo
>> Last name: foo
>> Full name: foo foo
>> Display name: foo foo
>> Initials: ff
>> Home directory: /home/foo
>> GECOS: foo foo
>> Login shell: /bin/sh
>> Kerberos principal: foo at T.VDA.LI
>> Email address: foo at t.vda.li
>> UID: 895600030
>> GID: 895600030
>> Password: False
>> Member of groups: ipausers
>> Kerberos keys available: False
>> # ipa user-add zed
>> First name: zed
>> Last name: zed
>> ----------------
>> Added user "zed"
>> ----------------
>> User login: zed
>> First name: zed
>> Last name: zed
>> Full name: zed zed
>> Display name: zed zed
>> Initials: zz
>> Home directory: /home/zed
>> GECOS: zed zed
>> Login shell: /bin/sh
>> Kerberos principal: zed at T.VDA.LI
>> Email address: zed at t.vda.li
>> UID: 895600031
>> GID: 895600031
>> Password: False
>> Member of groups: ipausers
>> Kerberos keys available: False
>> # ipa group-add-member foo-bar-zed --users={foo,bar,zed}
>> Group name: foo-bar-zed
>> GID: 895600028
>> Member users: foo, bar, zed
>> -------------------------
>> Number of members added 3
>> -------------------------
>> # ldapsearch -x -b cn=groups,cn=compat,dc=t,dc=vda,dc=li '(cn=foo-bar-zed)'
>> # extended LDIF
>> #
>> # LDAPv3
>> # base <cn=groups,cn=compat,dc=t,dc=vda,dc=li> with scope subtree
>> # filter: (cn=foo-bar-zed)
>> # requesting: ALL
>> #
>>
>> # foo-bar-zed, groups, compat, t.vda.li
>> dn: cn=foo-bar-zed,cn=groups,cn=compat,dc=t,dc=vda,dc=li
>> memberUid: foo
>> memberUid: bar
>> memberUid: zed
>> gidNumber: 895600028
>> objectClass: posixGroup
>> objectClass: groupOfUniqueNames
>> objectClass: top
>> uniqueMember: uid=foo,cn=users,cn=compat,dc=t,dc=vda,dc=li
>> uniqueMember: uid=bar,cn=users,cn=compat,dc=t,dc=vda,dc=li
>> uniqueMember: uid=zed,cn=users,cn=compat,dc=t,dc=vda,dc=li
>> cn: foo-bar-zed
>>
>> # search result
>> search: 2
>> result: 0 Success
>>
>> # numResponses: 2
>> # numEntries: 1
>>
>> -- / Alexander Bokovoy
> Thanks Alexander, that looks really promising. It also explains some of the strange behavior seen previously when I was testing the regsub element of ldiff.
>
> I'll get back to testing with vSphere now, but I imagine it'll now work fine.
>
> Thanks again,
>
> Sam
>
>
>
> ------------------------------
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
> End of Freeipa-users Digest, Vol 83, Issue 12
> *********************************************