Thank you for your answer but ... 2015-11-23 16:36 GMT+01:00 Simo Sorce <[email protected]>:
> On Wed, 2015-11-18 at 11:46 +0100, Domineaux Philippe wrote: > > Here is my environment : > > > > 1 Windows Domain > > Windows workstations > > Windows servers > > Multiple linux domains > > Linux workstations > > Linux servers > > > > Here is my goal : > > > > All users are centralized in the Active Directory. > > Users will authenticate on linux workstations with their AD accounts ( > > using POSIX attributes). > > Linux workstations must have access to NFS shares on Linux servers. > > Hi Domineaux, > you should look into setting up FreeIPA with a trust relationship to the > Windows Domain. > > That's already the case, I use the Trust relationship with POSIX attributes. > > What are the limitations ? > > It is hard to say what kind of limitations you are interested into, when > we trust AD, then AD users can access Linux machines, one limitation (if > you think it is a limitation) is that AD users will have fully qualified > names on the host (example: [email protected]) and not just flat names > to avoid name clashes between ipa users, local users and AD users. > > I'm ok with the use of fully qualified names, I use it to log in to my workstations. > > Windows users equals ipa users in term of services ? > > Yes. > > > Do I have to configure kerberos to also join directly the Windows > Kerberos > > Realm, > > or will IPA do the job to ask Windows server ? > > If you set up a trust between servers all is taken care of for you wrt > clients. > > > in etc/krb5.conf : > > > > includedir /var/lib/sss/pubconf/krb5.include.d/ > > > > [libdefaults] > > default_realm = IPA.ORG > > dns_lookup_realm = true > > dns_lookup_kdc = true > > rdns = false > > ticket_lifetime = 24h > > forwardable = yes > > udp_preference_limit = 0 > > default_ccache_name = KEYRING:persistent:%{uid} > > canonicalize = yes > > allow_weak_crypto = true > > > > [realms] > > IPA.ORG = { > > pkinit_anchors = FILE:/etc/ipa/ca.crt > > auth_to_local = RULE:[1:$1@ > > $0](^.*@WINDOMAIN.LOCAL$)s/@WINDOMAIN.LOCAL/@windomain.local/ > > auth_to_local = DEFAULT > > > > } > > > > ### IS THIS NECESSARY > > WINDOMAIN.LOCAL = { > > kdc = srvadipa.windomain.local > > admin_server = srvadipa.windomain.local > > } > > > > > > [domain_realm] > > .ipa.org = IPA.ORG > > ipa.org = IPA.ORG > > > > ### IS THIS NECESSARY > > > > .windomain.local = WINDOMAIN.LOCAL > > windomain.local = WINDOMAIN.LOCAL > > It depends on what client you are using, older RHEL may need this, newer > ones have an include directory in krb5.conf and sssd generates > appropriate configuration automatically based on server configuration. > > > Is the bug in libnfsidmap still active and prevents Windows users to > access > > to NFS4 krb5 secured shared folder ? > > I am not sure what bug you refer to. You may need to configure nfs > client nfs idmap, but I am not aware of bugs that will prevent it from > working right if properly configured. > > The bug specified below return me this on the NFS server (part of the ipa domain ) : Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: nfsdcb: authbuf=gss/krb5 authtype=user Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: Server : (user) id "650800001" -> name "[email protected]" Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: nfsdcb: authbuf=gss/krb5 authtype=group Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: Server : (group) id "650800001" -> name "[email protected]" Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: nfsdcb: authbuf=gss/krb5 authtype=user Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: Server : (user) id "65534" -> name "[email protected]" Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: nfsdcb: authbuf=gss/krb5 authtype=group Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: Server : (group) id "65534" -> name "[email protected]" Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: nfsdcb: authbuf=gss/krb5 authtype=user Nov 17 15:12:33 centos-nfs rpc.idmapd[6237]: nfsdcb: authbuf=gss/krb5 authtype=user Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: Server : (user) id "10002" -> name "[email protected][email protected]" Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: nfsdcb: authbuf=gss/krb5 authtype=group Nov 17 15:12:33 centos-nfs rpc.idmapd[6237]: nfs4_uid_to_name: calling nsswitch->uid_to_name Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: Server : (group) id "10047" -> name "[email protected][email protected]" Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: nfsdcb: authbuf=gss/krb5 authtype=user Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: Server : (user) id "0" -> name "[email protected]" Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: nfsdcb: authbuf=gss/krb5 authtype=group Nov 17 15:12:33 centos-nfs rpc.idmapd[4823]: Server : (group) id "0" -> name "[email protected]" Nov 17 15:12:33 centos-nfs rpc.idmapd[6237]: nfs4_uid_to_name: nsswitch->*uid_to_name returned 0* Nov 17 15:12:33 centos-nfs rpc.idmapd[6237]: nfs4_uid_to_name: *final return value is 0* Nov 17 15:12:33 centos-nfs rpc.idmapd[6237]: Server : (user) id "650800001" -> name "[email protected]" So it seems that for a native ipa user ( in my case testipa ) , the uid is return but for an AD user, it returns me zero. The result is that when I am logged on a workstation using an AD account I see nfs shares with nobody attributes. Specifically you may want to *not* try to consult LDAP from idmap, but > use a regex to transform the windows realm from upper case to lowercase > and then just use the getpwnam interface. > > As you can see on my krb5.conf there is already a regex for the ipa realm = auth_to_local = RULE:[1:$1@ > $0](^.*@WINDOMAIN.LOCAL$)s/@WINDOMAIN.LOCAL/@windomain.local/ > Simo. > > > I currently have > > > > bug here: > > https://www.redhat.com/archives/freeipa-users/2014-June/msg00163.html > > -- > > 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 > > > -- > Simo Sorce * Red Hat, Inc * New York > >
-- 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
