Re: [Freeipa-users] Kerberized NFS with Synology NAS
On Thu, 20 Aug 2015, Roberto Cornacchia wrote: I had Synology support inspect my configuration. They said that the authorization for the mapping looks for attribute GSSAuthName in LDAP, but doesn't find it. Therefore, they fall back to mapping it to nobody. Does this make sense to you? Is it true that GSSAuthName attribute isn't there? FreeIPA does not use UMich LDAP schema developed for NFS. Instead, as we store Kerberos principals in LDAP, for each Kerberos principal there is always krbPrincipalName attribute available. But on SSSD clients we instead recommend using SSSD-based identity mapping in /etc/idmap.conf (using sss module) as it is relying on SSSD caching capabilities and in general is more performance efficient. For direct use of UMich LDAP module in NFSv4 idmap you would have idmapd module to query LDAP server on each GSSAPI connection and since there is no state umich_ldap.so module, it will re-connect to LDAP every time which is highly inefficient. That's why I recommended to suggest Synology to integrate SSSD in their OS and have real benefits in improved Kerberos/AD/LDAP/FreeIPA support. On 13 August 2015 at 16:34, Alexander Bokovoy aboko...@redhat.com wrote: On Thu, 13 Aug 2015, Roberto Cornacchia wrote: After some more investigation, I feel the problem I described can be considered off topic, sorry about that. Initially I had the impression it could have been more freeIPA-related. It is sometimes difficult to tell whether the issue would show up regardless of using freeIPA or not. Should anyone be curious, these are my findings about using a Synology disk station for NFSv4+krb5 exports in my freeIPA domain: - Still no idea why I see all those Unspecified GSS failure from gssproxy on the client side. Google tells me that many before me have wondered about it. Has anyone a clue? - The NFS4+krb5 mounting works, but what I ran into is the nobody issue. NFSv4 relies on idmapd to map users correctly, but this goes wrong, hence the nobody issue - One first problem is that I had not set the domain. My bad. Fixed and got one step further. in idmapd.conf: Domain = hq.spinque.com - The second problem is that idmapd.conf in my synology says: Method=nsswitch GSS-Methods=static,synomap No idea what synomap would be, but I guess GSS-Methods should be more like static,nsswitch,synomap Indeed, everything works fine if I make static mappings for each LDAP user to a local user in Synology. But that's not how I want it. - Problem with all this is: no matter how I change these files, the next time I would save something from the Synology UI, these files would be overwritten Frustrating :( I would only suggest you to raise the problem with Synology support and convince them adding SSSD build and use it. SSSD has nfsidmap module 'sss' that does the right job on mapping based on what SSSD knows about Kerberos principals and user mapping for the domain. On 12 August 2015 at 13:33, Roberto Cornacchia roberto.cornacc...@gmail.com wrote: Enabled verbose output for rpc.idmapd as well, and now I see: nfsidmap[5034]: nss_getpwnam: name 'test1_l@localdomain' does not map into domain 'hq.spinque.com' On 12 August 2015 at 12:28, Roberto Cornacchia roberto.cornacc...@gmail.com wrote: I have used RPCGSSDARGS=-vvv RPCSVCGSSDARGS=-vvv in /etc/sysconfig/nfs , as suggested in http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Installing_the_IPA_Client_on_Linux.html In the excerpt below, taken during the mount, meson is the client, spinque03 is the nfs server (synology). It still doesn't tell me much, perhaps I'm missing something? rpc.gssd[838]: handling gssd upcall (nfs/clnt19) rpc.gssd[838]: handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 ' rpc.gssd[3328]: handling krb5 upcall (nfs/clnt19) rpc.gssd[3328]: process_krb5_upcall: service is 'null' rpc.gssd[3328]: Full hostname for 'spinque03.hq.spinque.com' is ' spinque03.hq.spinque.com' rpc.gssd[3328]: Full hostname for 'meson.hq.spinque.com' is ' meson.hq.spinque.com' rpc.gssd[3328]: No key table entry found for MESON$@HQ.SPINQUE.COM while getting keytab entry for 'MESON$@HQ.SPINQUE.COM' rpc.gssd[3328]: No key table entry found for root/ meson.hq.spinque@hq.spinque.com while getting keytab entry for 'root/ meson.hq.spinque@hq.spinque.com' rpc.gssd[3328]: No key table entry found for nfs/ meson.hq.spinque@hq.spinque.com while getting keytab entry for 'nfs/ meson.hq.spinque@hq.spinque.com' rpc.gssd[3328]: Success getting keytab entry for 'host/ meson.hq.spinque@hq.spinque.com' rpc.gssd[3328]: Successfully obtained machine credentials for principal 'host/meson.hq.spinque@hq.spinque.com' stored in ccache 'FILE:/tmp/ krb5ccmachine_HQ.SPINQUE.COM' rpc.gssd[3328]: INFO: Credentials in CC 'FILE:/tmp/ krb5ccmachine_HQ.SPINQUE.COM' are good until 1439461246 rpc.gssd[3328]: using FILE:/tmp/krb5ccmachine_HQ.SPINQUE.COM as credentials cache for machine creds
[Freeipa-users] private groups
Hi all, i am new using IPA and learning IPA i am also learning some other things new for me. Migrating our system to IPA i found some problems with private groups. We don’t used it up to now. Trying to disable this feature with ipa-managed-entries -e „UPG Definition“ -p xxx disable crashed my database. I don’t know why. After this i can’t create new users. For this problem i have no more information. But i have a question: Can i delete a private group after creating an user? How can i do this? And can i later create a private group again for this user? How? Thanx for any help! Detlev -- Detlev | Institut fuer Mikroelektronische Systeme Habicht | D-30167 Hannover +49 511 76219662 habi...@ims.uni-hannover.de + Handy+49 172 5415752 --- -- 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] Ubuntu Samba Server Auth against IPA
HI Guys, Anyone still a working clue/test here ? I didn't came further as it seems there need to be some domain join / match following the freeipa devs. Thanks! Matt 2015-08-13 13:09 GMT+02:00 Matt . yamakasi@gmail.com: Hi, I might have found somthing which I already seen in the logs. I did a smbpasswd my username on the samba server, it connects to ldap very well. I give my new password and get the following: smbldap_search_ext: base = [dc=my,dc=domain], filter = [((objectClass=ipaNTGroupAttrs)(|(ipaNTSecurityIdentifier=S-1my--sid---)))], scope = [2] Attribute [displayName] not found. Could not retrieve 'displayName' attribute from cn=Default SMB Group,cn=groups,cn=accounts,dc=my,dc=domain Sid S-1my--sid--- - MYDOMAIN\Default SMB Group(2) So something is missing! Thanks so far guys! Cheers, Matt 2015-08-13 12:02 GMT+02:00 Matt . yamakasi@gmail.com: Hi Youenn, OK thanks! this takes me a little but futher now and I see some good stuff in my logging. I'm testing on a Windows 10 Machine which is not member of an AD or so, so that might be my issue for now ? When testing on the samba box itself as my user I get: [myusername@smb-01 ~]$ smbclient //smb-01.domain.local/shares ... Checking NTLMSSP password for MSP\myusername failed: NT_STATUS_WRONG_PASSWORD ... SPNEGO login failed: NT_STATUS_WRONG_PASSWORD Maybe I have an issue with encrypted passwords ? When we have this all working, I think we have a howto :D Thanks! Matt 2015-08-13 10:53 GMT+02:00 Youenn PIOLET piole...@gmail.com: Hi Matt - CentOS : Did you copy ipasam.so and change your smb.conf accordingly? sambaSamAccount is not needed anymore that way. - Default IPA Way : won't work if your Windows is not part of a domain controller. DOMAIN\username may work for some users using Windows 7 - not 8 nor 10 (it did for me but I was the only one at the office... quite useless) This config may work on your CentOS (for the ipasam way): workgroup = TEST realm = TEST.NET kerberos method = dedicated keytab dedicated keytab file = FILE:/./samba.keytab create krb5 conf = no security = user encrypt passwords = true passdb backend = ipasam:ldaps://youripa.test.net ldapsam:trusted = yes ldapsuffix = test.net ldap user suffix = cn=users,cn=accounts ldap group suffix = cn=groups,cn=accounts -- Youenn Piolet piole...@gmail.com 2015-08-12 22:15 GMT+02:00 Matt . yamakasi@gmail.com: Hi, OK the default IPA way works great actually when testing it as described here: http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA On the samba server I can auth and see my share where I want to connect to. The issue is, on Windows I cannot auth, even when I do DOMAIN\username as username So, the IPA way should work. Any comments here ? Cheers, Matt 2015-08-12 19:00 GMT+02:00 Matt . yamakasi@gmail.com: HI GUys, I'm testing this out and I think I almost setup, this on a CentOS samba server. I'm using the ipa-adtrust way of Youeen but it seems we still need to add (objectclass=sambaSamAccount)) ? Info is welcome! I will report back when I have it working. Thanks! Matt 2015-08-10 11:16 GMT+02:00 Christopher Lamb christopher.l...@ch.ibm.com: The next route I will try - is the one Youeen took, using ipa-adtrust From: Matt . yamakasi@gmail.com To: Christopher Lamb/Switzerland/IBM@IBMCH, freeipa-users@redhat.com freeipa-users@redhat.com Date: 10.08.2015 10:03 Subject:Re: [Freeipa-users] Ubuntu Samba Server Auth against IPA Hi Chris, Okay this is good to hear. But don't we want a IPA managed Scheme ? When I did a ipa-adtrust-install --add-sids it also wanted a local installed Samba and I wonder why. Good that we make some progres on making it all clear. Cheers, Matt 2015-08-10 6:12 GMT+02:00 Christopher Lamb christopher.l...@ch.ibm.com: ldapsam + the samba extensions, pretty much as described in the Techslaves article. Once I have a draft for the wiki page, I will mail you. From: Matt . yamakasi@gmail.com To: Christopher Lamb/Switzerland/IBM@IBMCH, freeipa-users@redhat.com freeipa-users@redhat.com Date: 09.08.2015 21:17 Subject:Re: [Freeipa-users] Ubuntu Samba Server Auth against IPA Hi, Yes I know about anything but which way did you use now ? 2015-08-09 20:56 GMT+02:00 Christopher Lamb christopher.l...@ch.ibm.com: Hi Matt I am on OEL 7.1. - so anything that works on that should be good for RHEL and Centos 7.x I intend to add a how-to to the FreeIPA Wiki over the next few days. As we have suggested earlier, we will likely end up with several, one for each of the possible integration paths. Chris From: Matt . yamakasi@gmail.com To: Christopher Lamb/Switzerland/IBM@IBMCH,
Re: [Freeipa-users] Kerberized NFS with Synology NAS
I had Synology support inspect my configuration.
They said that the authorization for the mapping looks for attribute
GSSAuthName in LDAP, but doesn't find it. Therefore, they fall back to
mapping it to nobody.
Does this make sense to you? Is it true that GSSAuthName attribute isn't
there?
On 13 August 2015 at 16:34, Alexander Bokovoy aboko...@redhat.com wrote:
On Thu, 13 Aug 2015, Roberto Cornacchia wrote:
After some more investigation, I feel the problem I described can be
considered off topic, sorry about that. Initially I had the impression it
could have been more freeIPA-related.
It is sometimes difficult to tell whether the issue would show up
regardless of using freeIPA or not.
Should anyone be curious, these are my findings about using a Synology
disk
station for NFSv4+krb5 exports in my freeIPA domain:
- Still no idea why I see all those Unspecified GSS failure from
gssproxy
on the client side. Google tells me that many before me have wondered
about
it. Has anyone a clue?
- The NFS4+krb5 mounting works, but what I ran into is the nobody issue.
NFSv4 relies on idmapd to map users correctly, but this goes wrong, hence
the nobody issue
- One first problem is that I had not set the domain. My bad. Fixed and
got
one step further.
in idmapd.conf: Domain = hq.spinque.com
- The second problem is that idmapd.conf in my synology says:
Method=nsswitch
GSS-Methods=static,synomap
No idea what synomap would be, but I guess GSS-Methods should be more
like static,nsswitch,synomap
Indeed, everything works fine if I make static mappings for each LDAP
user to a local user in Synology. But that's not how I want it.
- Problem with all this is: no matter how I change these files, the next
time I would save something from the Synology UI, these files would be
overwritten
Frustrating :(
I would only suggest you to raise the problem with Synology support and
convince them adding SSSD build and use it. SSSD has nfsidmap module
'sss' that does the right job on mapping based on what SSSD knows about
Kerberos principals and user mapping for the domain.
On 12 August 2015 at 13:33, Roberto Cornacchia
roberto.cornacc...@gmail.com
wrote:
Enabled verbose output for rpc.idmapd as well, and now I see:
nfsidmap[5034]: nss_getpwnam: name 'test1_l@localdomain' does not map
into domain 'hq.spinque.com'
On 12 August 2015 at 12:28, Roberto Cornacchia
roberto.cornacc...@gmail.com wrote:
I have used
RPCGSSDARGS=-vvv
RPCSVCGSSDARGS=-vvv
in /etc/sysconfig/nfs , as suggested in
http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Installing_the_IPA_Client_on_Linux.html
In the excerpt below, taken during the mount, meson is the client,
spinque03 is the nfs server (synology).
It still doesn't tell me much, perhaps I'm missing something?
rpc.gssd[838]: handling gssd upcall (nfs/clnt19)
rpc.gssd[838]: handle_gssd_upcall: 'mech=krb5 uid=0
enctypes=18,17,16,23,3,1,2 '
rpc.gssd[3328]: handling krb5 upcall (nfs/clnt19)
rpc.gssd[3328]: process_krb5_upcall: service is 'null'
rpc.gssd[3328]: Full hostname for 'spinque03.hq.spinque.com' is '
spinque03.hq.spinque.com'
rpc.gssd[3328]: Full hostname for 'meson.hq.spinque.com' is '
meson.hq.spinque.com'
rpc.gssd[3328]: No key table entry found for MESON$@HQ.SPINQUE.COM
while
getting keytab entry for 'MESON$@HQ.SPINQUE.COM'
rpc.gssd[3328]: No key table entry found for root/
meson.hq.spinque@hq.spinque.com while getting keytab entry for
'root/
meson.hq.spinque@hq.spinque.com'
rpc.gssd[3328]: No key table entry found for nfs/
meson.hq.spinque@hq.spinque.com while getting keytab entry for
'nfs/
meson.hq.spinque@hq.spinque.com'
rpc.gssd[3328]: Success getting keytab entry for 'host/
meson.hq.spinque@hq.spinque.com'
rpc.gssd[3328]: Successfully obtained machine credentials for principal
'host/meson.hq.spinque@hq.spinque.com' stored in ccache 'FILE:/tmp/
krb5ccmachine_HQ.SPINQUE.COM'
rpc.gssd[3328]: INFO: Credentials in CC 'FILE:/tmp/
krb5ccmachine_HQ.SPINQUE.COM' are good until 1439461246
rpc.gssd[3328]: using FILE:/tmp/krb5ccmachine_HQ.SPINQUE.COM as
credentials cache for machine creds
rpc.gssd[3328]: using environment variable to select krb5 ccache
FILE:/tmp/krb5ccmachine_HQ.SPINQUE.COM
gssproxy[809]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.
Minor code may provide more information, No credentials cache found
gssproxy[798]: gssproxy[809]: (OID: { 1 2 840 113554 1 2 2 })
Unspecified
GSS failure. Minor code may provide more information, No credentials
cache
found
rpc.gssd[3328]: creating tcp client for server spinque03.hq.spinque.com
rpc.gssd[3328]: DEBUG: port already set to 2049
rpc.gssd[3328]: creating context with server
n...@spinque03.hq.spinque.com
rpc.gssd[3328]: DEBUG: serialize_krb5_ctx: lucid version!
rpc.gssd[3328]: prepare_krb5_rfc4121_buffer: protocol 1
rpc.gssd[3328]: prepare_krb5_rfc4121_buffer:
Re: [Freeipa-users] Kerberized NFS with Synology NAS
Thanks Alexander, That's the confirmation I was looking for. Indeed the Synology guy admitted it was their limitation. I have already made a feature request for SSSD. I guess for now I will just get it running with sec=sys. Best regards, Roberto On 20 August 2015 at 11:32, Alexander Bokovoy aboko...@redhat.com wrote: On Thu, 20 Aug 2015, Roberto Cornacchia wrote: I had Synology support inspect my configuration. They said that the authorization for the mapping looks for attribute GSSAuthName in LDAP, but doesn't find it. Therefore, they fall back to mapping it to nobody. Does this make sense to you? Is it true that GSSAuthName attribute isn't there? FreeIPA does not use UMich LDAP schema developed for NFS. Instead, as we store Kerberos principals in LDAP, for each Kerberos principal there is always krbPrincipalName attribute available. But on SSSD clients we instead recommend using SSSD-based identity mapping in /etc/idmap.conf (using sss module) as it is relying on SSSD caching capabilities and in general is more performance efficient. For direct use of UMich LDAP module in NFSv4 idmap you would have idmapd module to query LDAP server on each GSSAPI connection and since there is no state umich_ldap.so module, it will re-connect to LDAP every time which is highly inefficient. That's why I recommended to suggest Synology to integrate SSSD in their OS and have real benefits in improved Kerberos/AD/LDAP/FreeIPA support. On 13 August 2015 at 16:34, Alexander Bokovoy aboko...@redhat.com wrote: On Thu, 13 Aug 2015, Roberto Cornacchia wrote: After some more investigation, I feel the problem I described can be considered off topic, sorry about that. Initially I had the impression it could have been more freeIPA-related. It is sometimes difficult to tell whether the issue would show up regardless of using freeIPA or not. Should anyone be curious, these are my findings about using a Synology disk station for NFSv4+krb5 exports in my freeIPA domain: - Still no idea why I see all those Unspecified GSS failure from gssproxy on the client side. Google tells me that many before me have wondered about it. Has anyone a clue? - The NFS4+krb5 mounting works, but what I ran into is the nobody issue. NFSv4 relies on idmapd to map users correctly, but this goes wrong, hence the nobody issue - One first problem is that I had not set the domain. My bad. Fixed and got one step further. in idmapd.conf: Domain = hq.spinque.com - The second problem is that idmapd.conf in my synology says: Method=nsswitch GSS-Methods=static,synomap No idea what synomap would be, but I guess GSS-Methods should be more like static,nsswitch,synomap Indeed, everything works fine if I make static mappings for each LDAP user to a local user in Synology. But that's not how I want it. - Problem with all this is: no matter how I change these files, the next time I would save something from the Synology UI, these files would be overwritten Frustrating :( I would only suggest you to raise the problem with Synology support and convince them adding SSSD build and use it. SSSD has nfsidmap module 'sss' that does the right job on mapping based on what SSSD knows about Kerberos principals and user mapping for the domain. On 12 August 2015 at 13:33, Roberto Cornacchia roberto.cornacc...@gmail.com wrote: Enabled verbose output for rpc.idmapd as well, and now I see: nfsidmap[5034]: nss_getpwnam: name 'test1_l@localdomain' does not map into domain 'hq.spinque.com' On 12 August 2015 at 12:28, Roberto Cornacchia roberto.cornacc...@gmail.com wrote: I have used RPCGSSDARGS=-vvv RPCSVCGSSDARGS=-vvv in /etc/sysconfig/nfs , as suggested in http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Installing_the_IPA_Client_on_Linux.html In the excerpt below, taken during the mount, meson is the client, spinque03 is the nfs server (synology). It still doesn't tell me much, perhaps I'm missing something? rpc.gssd[838]: handling gssd upcall (nfs/clnt19) rpc.gssd[838]: handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 ' rpc.gssd[3328]: handling krb5 upcall (nfs/clnt19) rpc.gssd[3328]: process_krb5_upcall: service is 'null' rpc.gssd[3328]: Full hostname for 'spinque03.hq.spinque.com' is ' spinque03.hq.spinque.com' rpc.gssd[3328]: Full hostname for 'meson.hq.spinque.com' is ' meson.hq.spinque.com' rpc.gssd[3328]: No key table entry found for MESON$@HQ.SPINQUE.COM while getting keytab entry for 'MESON$@HQ.SPINQUE.COM' rpc.gssd[3328]: No key table entry found for root/ meson.hq.spinque@hq.spinque.com while getting keytab entry for 'root/ meson.hq.spinque@hq.spinque.com' rpc.gssd[3328]: No key table entry found for nfs/ meson.hq.spinque@hq.spinque.com while getting keytab entry for 'nfs/ meson.hq.spinque@hq.spinque.com' rpc.gssd[3328]: Success getting keytab entry for 'host/
Re: [Freeipa-users] FreeIPA state - performace, commercial usage
On 08/20/2015 10:44 PM, Vaclav Adamec wrote: Hi, Don't want to start flame, but my question is quite simple, is there anybody who use it in real production/commercial setup without any major issues ? don't you lack commercial support ? no issues with auditors ? after a year/two of usage/testing/troubleshooting of freeipa/redhat ipa it seems, for me as a simple admin, to be still not very mature project, even basic configuration isn't very stable/solid to use it in real production. I started with latest freeipa on fedora with one server (VM vmware), then add other master replicas but after many issues I carefully keep one server on redhat 7 with up2date version of ipa from rhel repos, default installation setup, no replication. But still with stability issue (processes died occasionally, mostly due multiple clients removing, sometimes it dies completely with cryptic errors in journal (but sometimes no errors at all just wait for something during restart) and only fast option is restore from snaphot backups with loosing some clients). Performance is also issue, we cannot register more then 4-5 servers at once, or it will timeout (but no visible network or cpu/mem load issue). As there are no other complex solutions like IPA it's quite hard decide what to use as a replacement, but right now it's seems that we have no other option and we probably switch to simple openldap and missing functionality cover by puppet and some 2factor solution. We don't need anything special, no dns handling, no certificates, no AD connection, just simple servers/clients, users with groups and rules for access/sudo. Multimaster (with DNS SRV) solution for higher performance and reliability would be nice, but not necessary if we can keep it stable and handle more clients registration. We have tens of users/groups, hundreds servers/clients with random registration burst as we use it also for temp. build environments and OpenStack instances. Oficial support from RedHat is not very helpful, also they don't provide any real training for IPA, so only option is mail conference (very helpful, thanks for that) and tones of documentation/examples for variety of versions, but for such complex thing probably not enough for commercial use. Can I ask you for your opinion ? Vasek It seems that you have already contacted Red Hat support. Have you filed cases? Have you shared your logs? If you had bad experience wit hRed Hat support organization please contact me offline and share the details. If you have consistent problems we want them fixed. As a Red Hat representative I can definitely say that we have many customers running IdM in production. It is true that Red Hat does not provide formal training. We here try to compensate for that part as much as possible. It is also a commercial opportunity for someone who figured things out and is ready to help others. HTH -- Thank you, Dmitri Pal Engineering Director, Identity Management and Platform Security 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] Dns SOA MNAME not resolving from LDAP data
On 08/20/2015 01:48 PM, David Dejaeghere wrote: Hi, I noticed that changing the authoritarive nameserver in FreeIPA reflects correctly to its directory data but bind will not resolve the soa record with the updated mname details. For example I add a zone test.be http://test.be and change the mname record. [root@ns02 ~]# ipa dnszone-add Zone name: test.be http://test.be Zone name: test.be http://test.be. Active zone: TRUE * Authoritative nameserver: ns02.tokiogroup.be http://ns02.tokiogroup.be.* Administrator e-mail address: hostmaster SOA serial: 1440070999 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant TOKIOGROUP.BE http://TOKIOGROUP.BE krb5-self * A; grant TOKIOGROUP.BE http://TOKIOGROUP.BE krb5-self * ; grant TOKIOGROUP.BE http://TOKIOGROUP.BE krb5-self * SSHFP; Dynamic update: FALSE Allow query: any; Allow transfer: none; [root@ns02 ~]# ipa dnszone-mod --nameserver anaconda-ks.cfg .bash_logout .bashrc .ipa/.ssh/ .bash_history.bash_profile.cshrc .pki/.tcshrc [root@ns02 ~]# ipa dnszone-mod --name-server*ns7.tokiogroup.be http://ns7.tokiogroup.be*. Zone name: test.be http://test.be ipa: WARNING: Semantic of setting Authoritative nameserver was changed. It is used only for setting the SOA MNAME attribute. NS record(s) can be edited in zone apex - '@'. Zone name: test.be http://test.be. Active zone: TRUE *Authoritative nameserver: ns7.tokiogroup.be http://ns7.tokiogroup.be.* Administrator e-mail address: hostmaster SOA serial: 1440071001 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Allow query: any; Allow transfer: none; [root@ns02 ~]# nslookup set q=SOA test.be http://test.be Server: 127.0.0.1 Address:127.0.0.1#53 test.be http://test.be *origin = ns02.tokiogroup.be http://ns02.tokiogroup.be* mail addr = hostmaster.test.be http://hostmaster.test.be serial = 1440071001 refresh = 3600 retry = 900 expire = 1209600 minimum = 3600 As you can see the SOA record still shows the original default value. Kind Regards, David Dejaeghere Thank you for this bug report. I opened bind-dyndb-ldap ticket https://fedorahosted.org/bind-dyndb-ldap/ticket/159 Martin -- 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] private groups
On 08/20/2015 11:57 AM, Detlev Habicht wrote: Hi all, i am new using IPA and learning IPA i am also learning some other things new for me. Migrating our system to IPA i found some problems with private groups. We don’t used it up to now. Trying to disable this feature with ipa-managed-entries -e „UPG Definition“ -p xxx disable crashed my database. By crashed, you mean that Directory Server process crashed? If yes, it would be really interesting to get a stack trace, steps in http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debug_crashes This would allow 389-DS developers to fix the bug. I don’t know why. After this i can’t create new users. IIRC, you would need to turn the default ipausers group into POSIX group (group-mod --posix), to let it be used it instead of the user private groups. But this depends on the error you are getting. For this problem i have no more information. But i have a question: Can i delete a private group after creating an user? How can i do this? You can use group-detach command and then group-del on the detached managed group. And can i later create a private group again for this user? How? Hmm... You could do group-add command with the right GID, I do not know about single command doing that. Thanx for any help! Detlev -- Detlev | Institut fuer Mikroelektronische Systeme Habicht | D-30167 Hannover +49 511 76219662 habi...@ims.uni-hannover.de + Handy+49 172 5415752 --- -- 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] private groups
Well, it is not really a server crash … the server is running, but i cannot create new users. But i will try it again and will send the results. Detlev -- Detlev | Institut fuer Mikroelektronische Systeme Habicht | D-30167 Hannover +49 511 76219662 habi...@ims.uni-hannover.de + Handy+49 172 5415752 --- Am 20.08.2015 um 12:54 schrieb Martin Kosek mko...@redhat.com: On 08/20/2015 11:57 AM, Detlev Habicht wrote: Hi all, i am new using IPA and learning IPA i am also learning some other things new for me. Migrating our system to IPA i found some problems with private groups. We don’t used it up to now. Trying to disable this feature with ipa-managed-entries -e „UPG Definition“ -p xxx disable crashed my database. By crashed, you mean that Directory Server process crashed? If yes, it would be really interesting to get a stack trace, steps in http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debug_crashes This would allow 389-DS developers to fix the bug. I don’t know why. After this i can’t create new users. IIRC, you would need to turn the default ipausers group into POSIX group (group-mod --posix), to let it be used it instead of the user private groups. But this depends on the error you are getting. For this problem i have no more information. But i have a question: Can i delete a private group after creating an user? How can i do this? You can use group-detach command and then group-del on the detached managed group. And can i later create a private group again for this user? How? Hmm... You could do group-add command with the right GID, I do not know about single command doing that. Thanx for any help! Detlev -- Detlev | Institut fuer Mikroelektronische Systeme Habicht | D-30167 Hannover +49 511 76219662 habi...@ims.uni-hannover.de + Handy+49 172 5415752 --- -- 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] How to modify the logging dir
Hello. I send you this mail because I'm looking for a way to modify the logging dir of the different components embedded with FreeIPA. I already check here : http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/server-config.html But I cannot see how to modify the logging dir of sssd ? Is that possible ? I checked lighlty the man of sssd.conf but didn't find a way to modify the logging dir. Best regards. Bahan -- 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] Dns SOA MNAME not resolving from LDAP data
Hi, I noticed that changing the authoritarive nameserver in FreeIPA reflects correctly to its directory data but bind will not resolve the soa record with the updated mname details. For example I add a zone test.be and change the mname record. [root@ns02 ~]# ipa dnszone-add Zone name: test.be Zone name: test.be. Active zone: TRUE * Authoritative nameserver: ns02.tokiogroup.be http://ns02.tokiogroup.be.* Administrator e-mail address: hostmaster SOA serial: 1440070999 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant TOKIOGROUP.BE krb5-self * A; grant TOKIOGROUP.BE krb5-self * ; grant TOKIOGROUP.BE krb5-self * SSHFP; Dynamic update: FALSE Allow query: any; Allow transfer: none; [root@ns02 ~]# ipa dnszone-mod --nameserver anaconda-ks.cfg .bash_logout .bashrc .ipa/.ssh/ .bash_history.bash_profile.cshrc .pki/.tcshrc [root@ns02 ~]# ipa dnszone-mod --name-server* ns7.tokiogroup.be http://ns7.tokiogroup.be*. Zone name: test.be ipa: WARNING: Semantic of setting Authoritative nameserver was changed. It is used only for setting the SOA MNAME attribute. NS record(s) can be edited in zone apex - '@'. Zone name: test.be. Active zone: TRUE *Authoritative nameserver: ns7.tokiogroup.be http://ns7.tokiogroup.be.* Administrator e-mail address: hostmaster SOA serial: 1440071001 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Allow query: any; Allow transfer: none; [root@ns02 ~]# nslookup set q=SOA test.be Server: 127.0.0.1 Address:127.0.0.1#53 test.be * origin = ns02.tokiogroup.be http://ns02.tokiogroup.be* mail addr = hostmaster.test.be serial = 1440071001 refresh = 3600 retry = 900 expire = 1209600 minimum = 3600 As you can see the SOA record still shows the original default value. Kind Regards, David Dejaeghere -- 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] Users can't login on some systems.
Thanks for the reply, I did not clear out /var/lib/sss/db before re-installation. I'll give it a try. I'll stop the service clear the db then restart and see if that helps. If not I'll uninstall the client remove the db and then reinstall the client. Unless it's too late and anyone has a better idea. -Chris On 8/20/2015 7:19 PM, Prasun Gera wrote: Did you clear out /var/lib/sss/db between re-installation of the client? There was a bug which might not have been fixed downstream yet. On Thu, Aug 20, 2015 at 1:21 PM, Chris Mohler cmoh...@oberlin.edu mailto:cmoh...@oberlin.edu wrote: Hi List, I'm still fairly new to this list and administrating FreeIPA. I had a very old version of freeipa and had all sorts of odd issues with it. I had 47 ubuntu clients attached to the domain. I setup a newer freeipa server version: 4.1.4 I recreated all my user accounts by hand I did not migrate any of them. I then removed the 47 clients from the old domain #ipa-client-install --uninstall Then I reinstalled each client #ipa-client-install --domain=cs.oberlin.edu http://cs.oberlin.edu --realm=CS.OBERLIN.EDU http://CS.OBERLIN.EDU -p admin -W --hostname `hostname` -N it finished without errors on all my systems. two of my systems will not let any ipa users login via ssh or the console. the rest of them work fine. After keying in the password I get the following. Permission denied, please try again. id (username) shows the UID and GID and Groups correctly. getent passwd shows only my local accounts I don't have enumerate on. kinit also works. _my auth.log shows this_ pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=132.162.201.237 user=HIDDEN pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=132.162.201.237 user=HIDDEN pam_sss(sshd:auth): received for user : 7 (Authentication failure) I know it's the correct password as it works on the other clients. _I get this in krb5_child.log_ [[sssd[krb5_child[10546 [unpack_buffer] (0x0100): cmd [241] uid [66133] gid [100] validate [true] enterprise principal [false] offline [false] UPN [@CS.OBERLIN.EDU http://CS.OBERLIN.EDU] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_66133_XX] keytab: [/etc/krb5.keytab] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/occs.cs.oberlin@cs.oberlin.edu mailto:host/occs.cs.oberlin@cs.oberlin.edu] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [match_principal] (0x1000): Principal matched to the sample (host/occs.cs.oberlin@cs.oberlin.edu mailto:host/occs.cs.oberlin@cs.oberlin.edu). (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [check_fast_ccache] (0x0200): FAST TGT is still valid. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [main] (0x0400): Will perform online auth (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [tgt_req_child] (0x1000): Attempting to get a TGT (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [get_and_save_tgt] (0x0400): Attempting kinit for realm [CS.OBERLIN.EDU http://CS.OBERLIN.EDU] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [validate_tgt] (0x0400): TGT verified using key for [host/occs.cs.oberlin@cs.oberlin.edu mailto:host/occs.cs.oberlin@cs.oberlin.edu]. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [become_user] (0x0200): Trying to become user [66133][100]. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [k5c_send_data] (0x0200): Received error code 0 (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [main] (0x0400): krb5_child completed successfully (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [main] (0x0400): krb5_child started. (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [unpack_buffer] (0x1000): total buffer size: [127] (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [unpack_buffer] (0x0100): cmd [241] uid [66133] gid [100] validate [true] enterprise principal [false] offline [false] UPN [@CS.OBERLIN.EDU http://CS.OBERLIN.EDU] _sssd.conf on the broken machine_ [domain/cs.oberlin.edu http://cs.oberlin.edu] debug_level=8
[Freeipa-users] FreeIPA state - performace, commercial usage
Hi, Don't want to start flame, but my question is quite simple, is there anybody who use it in real production/commercial setup without any major issues ? don't you lack commercial support ? no issues with auditors ? after a year/two of usage/testing/troubleshooting of freeipa/redhat ipa it seems, for me as a simple admin, to be still not very mature project, even basic configuration isn't very stable/solid to use it in real production. I started with latest freeipa on fedora with one server (VM vmware), then add other master replicas but after many issues I carefully keep one server on redhat 7 with up2date version of ipa from rhel repos, default installation setup, no replication. But still with stability issue (processes died occasionally, mostly due multiple clients removing, sometimes it dies completely with cryptic errors in journal (but sometimes no errors at all just wait for something during restart) and only fast option is restore from snaphot backups with loosing some clients). Performance is also issue, we cannot register more then 4-5 servers at once, or it will timeout (but no visible network or cpu/mem load issue). As there are no other complex solutions like IPA it's quite hard decide what to use as a replacement, but right now it's seems that we have no other option and we probably switch to simple openldap and missing functionality cover by puppet and some 2factor solution. We don't need anything special, no dns handling, no certificates, no AD connection, just simple servers/clients, users with groups and rules for access/sudo. Multimaster (with DNS SRV) solution for higher performance and reliability would be nice, but not necessary if we can keep it stable and handle more clients registration. We have tens of users/groups, hundreds servers/clients with random registration burst as we use it also for temp. build environments and OpenStack instances. Oficial support from RedHat is not very helpful, also they don't provide any real training for IPA, so only option is mail conference (very helpful, thanks for that) and tones of documentation/examples for variety of versions, but for such complex thing probably not enough for commercial use. Can I ask you for your opinion ? Vasek -- 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] Users can't login on some systems.
Did you clear out /var/lib/sss/db between re-installation of the client? There was a bug which might not have been fixed downstream yet. On Thu, Aug 20, 2015 at 1:21 PM, Chris Mohler cmoh...@oberlin.edu wrote: Hi List, I'm still fairly new to this list and administrating FreeIPA. I had a very old version of freeipa and had all sorts of odd issues with it. I had 47 ubuntu clients attached to the domain. I setup a newer freeipa server version: 4.1.4 I recreated all my user accounts by hand I did not migrate any of them. I then removed the 47 clients from the old domain #ipa-client-install --uninstall Then I reinstalled each client #ipa-client-install --domain=cs.oberlin.edu --realm=CS.OBERLIN.EDU -p admin -W --hostname `hostname` -N it finished without errors on all my systems. two of my systems will not let any ipa users login via ssh or the console. the rest of them work fine. After keying in the password I get the following. Permission denied, please try again. id (username) shows the UID and GID and Groups correctly. getent passwd shows only my local accounts I don't have enumerate on. kinit also works. *my auth.log shows this* pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=132.162.201.237 user=HIDDEN pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=132.162.201.237 user=HIDDEN pam_sss(sshd:auth): received for user : 7 (Authentication failure) I know it's the correct password as it works on the other clients. *I get this in krb5_child.log* [[sssd[krb5_child[10546 [unpack_buffer] (0x0100): cmd [241] uid [66133] gid [100] validate [true] enterprise principal [false] offline [false] UPN [@CS.OBERLIN.EDU] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_66133_XX] keytab: [/etc/krb5.keytab] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [ host/occs.cs.oberlin@cs.oberlin.edu] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [match_principal] (0x1000): Principal matched to the sample ( host/occs.cs.oberlin@cs.oberlin.edu). (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [check_fast_ccache] (0x0200): FAST TGT is still valid. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [main] (0x0400): Will perform online auth (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [tgt_req_child] (0x1000): Attempting to get a TGT (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [get_and_save_tgt] (0x0400): Attempting kinit for realm [CS.OBERLIN.EDU] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [validate_tgt] (0x0400): TGT verified using key for [ host/occs.cs.oberlin@cs.oberlin.edu]. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [become_user] (0x0200): Trying to become user [66133][100]. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [k5c_send_data] (0x0200): Received error code 0 (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [main] (0x0400): krb5_child completed successfully (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [main] (0x0400): krb5_child started. (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [unpack_buffer] (0x1000): total buffer size: [127] (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [unpack_buffer] (0x0100): cmd [241] uid [66133] gid [100] validate [true] enterprise principal [false] offline [false] UPN [@CS.OBERLIN.EDU] *sssd.conf on the broken machine* [domain/cs.oberlin.edu] debug_level=8 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = cs.oberlin.edu id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = occs.cs.oberlin.edu chpass_provider = ipa ipa_server = _srv_, ipa1.cs.oberlin.edu ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam, ssh config_file_version = 2 debug_level=8 domains = cs.oberlin.edu [nss] debug_level=8 [pam] debug_level=8 [sudo] [autofs] [ssh] debug_level=8 [pac] *The broken systems sssd_nss.log *[nss_cmd_getpwnam_search] (0x0400): Returning info for user [hid...@cs.oberlin.edu] [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [17] with input [HIDDEN]. [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'HIDDEN' matched without domain, user is HIDDEN [sssd[nss]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] [sssd[nss]] [nss_cmd_getbynam] (0x0100):
Re: [Freeipa-users] Users can't login on some systems.
Wow That totally fixed it! Thanks again. I simply stopped the sssd service removed the db and then started the sssd service again. My first attempt to login took a few seconds and was successful. I did not have to reinstall the client or even reboot the system. FWIW I put the commands in a script sssflush.sh /sbin/initctl stop sssd rm /var/lib/sss/db/* /sbin/initctl start sssd I've needed to do this a few times before. A note to fellow Ubuntu users service sssd stop doesn't work when you put it in a script. Use /sbin/initctl instead. -Chris On 8/20/2015 7:19 PM, Prasun Gera wrote: Did you clear out /var/lib/sss/db between re-installation of the client? There was a bug which might not have been fixed downstream yet. On Thu, Aug 20, 2015 at 1:21 PM, Chris Mohler cmoh...@oberlin.edu mailto:cmoh...@oberlin.edu wrote: Hi List, I'm still fairly new to this list and administrating FreeIPA. I had a very old version of freeipa and had all sorts of odd issues with it. I had 47 ubuntu clients attached to the domain. I setup a newer freeipa server version: 4.1.4 I recreated all my user accounts by hand I did not migrate any of them. I then removed the 47 clients from the old domain #ipa-client-install --uninstall Then I reinstalled each client #ipa-client-install --domain=cs.oberlin.edu http://cs.oberlin.edu --realm=CS.OBERLIN.EDU http://CS.OBERLIN.EDU -p admin -W --hostname `hostname` -N it finished without errors on all my systems. two of my systems will not let any ipa users login via ssh or the console. the rest of them work fine. After keying in the password I get the following. Permission denied, please try again. id (username) shows the UID and GID and Groups correctly. getent passwd shows only my local accounts I don't have enumerate on. kinit also works. _my auth.log shows this_ pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=132.162.201.237 user=HIDDEN pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=132.162.201.237 user=HIDDEN pam_sss(sshd:auth): received for user : 7 (Authentication failure) I know it's the correct password as it works on the other clients. _I get this in krb5_child.log_ [[sssd[krb5_child[10546 [unpack_buffer] (0x0100): cmd [241] uid [66133] gid [100] validate [true] enterprise principal [false] offline [false] UPN [@CS.OBERLIN.EDU http://CS.OBERLIN.EDU] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_66133_XX] keytab: [/etc/krb5.keytab] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/occs.cs.oberlin@cs.oberlin.edu mailto:host/occs.cs.oberlin@cs.oberlin.edu] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [match_principal] (0x1000): Principal matched to the sample (host/occs.cs.oberlin@cs.oberlin.edu mailto:host/occs.cs.oberlin@cs.oberlin.edu). (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [check_fast_ccache] (0x0200): FAST TGT is still valid. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [main] (0x0400): Will perform online auth (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [tgt_req_child] (0x1000): Attempting to get a TGT (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [get_and_save_tgt] (0x0400): Attempting kinit for realm [CS.OBERLIN.EDU http://CS.OBERLIN.EDU] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [validate_tgt] (0x0400): TGT verified using key for [host/occs.cs.oberlin@cs.oberlin.edu mailto:host/occs.cs.oberlin@cs.oberlin.edu]. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [become_user] (0x0200): Trying to become user [66133][100]. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [k5c_send_data] (0x0200): Received error code 0 (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [main] (0x0400): krb5_child completed successfully (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [main] (0x0400): krb5_child started. (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [unpack_buffer] (0x1000): total buffer size: [127] (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [unpack_buffer] (0x0100): cmd [241] uid [66133]
Re: [Freeipa-users] FreeIPA state - performace, commercial usage
On 08/21/2015 09:44 AM, Vaclav Adamec wrote: Hi, Don't want to start flame, but my question is quite simple, is there anybody who use it in real production/commercial setup without any major issues ? don't you lack commercial support ? no issues with auditors ? FreeIPA is upstream for Red Hat IdM, if you wanna get commercial/enterprise support, go for Red Hat Subscription. after a year/two of usage/testing/troubleshooting of freeipa/redhat ipa it seems, for me as a simple admin, to be still not very mature project, even basic configuration isn't very stable/solid to use it in real production. I started with latest freeipa on fedora with one server (VM vmware), then add other master replicas but after many issues I carefully keep one server on redhat 7 with up2date version of ipa from rhel repos, default installation setup, no replication. But still with stability issue (processes died occasionally, mostly due multiple clients removing, sometimes it dies completely with cryptic errors in journal (but sometimes no errors at all just wait for something during restart) and only fast option is restore from snaphot backups with loosing some clients). Performance is also issue, we cannot register more then 4-5 servers at once, or it will timeout (but no visible network or cpu/mem load issue). As there are no other complex solutions like IPA it's quite hard decide what to use as a replacement, but right now it's seems that we have no other option and we probably switch to simple openldap and missing functionality cover by puppet and some 2factor solution. We don't need anything special, no dns handling, no certificates, no AD connection, just simple servers/clients, users with groups and rules for access/sudo. Multimaster (with DNS SRV) solution for higher performance and reliability would be nice, but not necessary if we can keep it stable and handle more clients registration. We have tens of users/groups, hundreds servers/clients with random registration burst as we use it also for temp. build environments and OpenStack instances. Oficial support from RedHat is not very helpful, also they don't provide any real training for IPA, so only option is mail conference (very helpful, thanks for that) and tones of documentation/examples for variety of versions, but for such complex thing probably not enough for commercial use. IMHO, there's no official support from Red Hat on FreeIPA, I was though it was community support. If you wanna official support or real training for IdM (Identity Management) from Red Hat, go to https://access.redhat.com/products/Identity_Management Can I ask you for your opinion ? Vasek -- 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] How to modify the logging dir
bahan w wrote: Hello. I send you this mail because I'm looking for a way to modify the logging dir of the different components embedded with FreeIPA. I already check here : http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/server-config.html But I cannot see how to modify the logging dir of sssd ? Is that possible ? I checked lighlty the man of sssd.conf but didn't find a way to modify the logging dir. May I ask why you want to change the logging directory? And for which services, all of them? rob -- 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] Questions to compat LDAP suffix
Detlev Habicht wrote: Hi all, i am very new using and testing IPA and i have some questions, which are not really IPA topics. But perhaps someone can help me and send me a link, where i can read and learn such things: I see in the LDAP tree a suffix like this: cn=users,cn=compat,dc=ims,dc=intern And of course this: cn=users,cn=accounts,dc=ims,dc=intern I don’t understand the reason for „cn=compat“. Where do i find some infos to understand this concept? It is the schema comppatibility tree. IPA servers the 2307bis schema. Some clients (Solaris) want 2307 so need to use the cn=compat tree instead. It is also being leveraged for providing separate views for entries. You can find more information on this in /usr/share/doc/slapi-nis/ipa/sch-ipa.txt Documentation on the plugin can be found in /usr/share/doc/slapi-nis. The basic rule of thumb though is to search in the right container for the right kind of entry rather than searching from the base. rob -- 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] Questions to compat LDAP suffix
Hi all, i am very new using and testing IPA and i have some questions, which are not really IPA topics. But perhaps someone can help me and send me a link, where i can read and learn such things: I see in the LDAP tree a suffix like this: cn=users,cn=compat,dc=ims,dc=intern And of course this: cn=users,cn=accounts,dc=ims,dc=intern I don’t understand the reason for „cn=compat“. Where do i find some infos to understand this concept? Thanx. Detlev -- Detlev | Institut fuer Mikroelektronische Systeme Habicht | D-30167 Hannover +49 511 76219662 habi...@ims.uni-hannover.de + Handy+49 172 5415752 --- -- 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] private groups
Martin Kosek wrote: On 08/20/2015 11:57 AM, Detlev Habicht wrote: Hi all, i am new using IPA and learning IPA i am also learning some other things new for me. Migrating our system to IPA i found some problems with private groups. We don’t used it up to now. Trying to disable this feature with ipa-managed-entries -e „UPG Definition“ -p xxx disable crashed my database. By crashed, you mean that Directory Server process crashed? If yes, it would be really interesting to get a stack trace, steps in http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debug_crashes This would allow 389-DS developers to fix the bug. I don’t know why. After this i can’t create new users. IIRC, you would need to turn the default ipausers group into POSIX group (group-mod --posix), to let it be used it instead of the user private groups. But this depends on the error you are getting. For this problem i have no more information. But i have a question: Can i delete a private group after creating an user? How can i do this? You can use group-detach command and then group-del on the detached managed group. And can i later create a private group again for this user? How? Hmm... You could do group-add command with the right GID, I do not know about single command doing that. There is no way to create the same kind of UPG for an existing user as can be done for a new user. The managed entries plugin manages the linkage between the user and group and IPA currently doesn't provide a way to create a linkage after the fact. You can create a group with the same gid with : ipa group-add myuser --gid uid-of-user, but this isn't exactly private. A private group doesn't allow members. One of the other features of UPG is that when the user is deleted, the group is also deleted. This would not happen in the case of manually created private groups. rob -- 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] Question on FreeIPA OpenSSH PubKey Authentication
On Thu, 20 Aug 2015, Yogesh Sharma wrote: Hi, I was reading this slide https://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf; to troubleshoot an issue which we are facing while IPA to allow user using public Key authentication and had few questions: 1. Where does IPA stores the User Public Keys, I can fetch them using sss_ssh_authorizedkeys but would be good if I we can know from where it fetches the keys. Is it in LDAP DB. They are stored in the user entry in LDAP. Use 'ipa user-show user --raw --all' to see it. 2. When I registered new users with PubKey Authentication, some of them are working fine and some got prompted for Password (this also happen when we update their public key). This usually happens when either SSH is not able to pick the private key (id_rsa) or if there is some permission issue with .ssh or authorized_keys file. I am trying to find this in IPA environment as why this is happening for certain users only though it is picking the right private_key and client side. SSSD logs and secure logs does not have much to say except authentication failed. private keys are used by SSH client, so you can enable debugging output when using SSH client to see if it has issues with file system access. This has nothing to do with FreeIPA at all. 4. As per the above slide, OpenSSH Integration with SSSD Slide 2 says, that add know_hosts file with SSSD, However, Neither IPA Client nor IPA Server has this Configure ssh in /etc/ssh/ssh_config Get known_hosts from SSSD GlobalKnownHostsFile /var/lib/sss/pubconf/known_hosts ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h This part is automatically configured if you choose to configure SSSD and SSSD has support for knownhostsproxy. See ipa-client/ipa-install/ipa-client-install:configure_ssh_config() (or directly in /sbin/ipa-client-install). -- / Alexander Bokovoy -- 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] freeipa on http?
On Tue, Aug 18, 2015 at 02:58:50PM -0700, Janelle wrote:
Tried that -- but it gives a blank screen. I will try playing with it some
more. At least I know we are thinking in the same ballpark
I was able to set this up just fine with
freeipa-server-4.1.4-4.fc22.x86_64. You need to disable the
# Redirect to the secure port if not displaying an error or retrieving
# configuration.
RewriteCond %{SERVER_PORT} !^443$
RewriteCond %{REQUEST_URI} !^/ipa/(errors|config|crl)
RewriteCond %{REQUEST_URI}
!^/ipa/[^\?]+(\.js|\.css|\.png|\.gif|\.ico|\.woff|\.svg|\.ttf|\.eot)$
RewriteRule ^/ipa/(.*) https://ipa.example.test/ipa/$1 [L,R=301,NC]
part on the IPA server or you will get infinite redirection loop.
Also you will need to test it through that SSL proxy, not directly
against http://ipa.example.test/, or authentication on the WebUI will
not work -- the session cookie is marked as Secure so the browser will
not store it when it comes via http, plus the UI checks referer to
start with https://.
--
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat
--
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] Question on FreeIPA OpenSSH PubKey Authentication
Hi, I was reading this slide https://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf; to troubleshoot an issue which we are facing while IPA to allow user using public Key authentication and had few questions: 1. Where does IPA stores the User Public Keys, I can fetch them using sss_ssh_authorizedkeys but would be good if I we can know from where it fetches the keys. Is it in LDAP DB. 2. When I registered new users with PubKey Authentication, some of them are working fine and some got prompted for Password (this also happen when we update their public key). This usually happens when either SSH is not able to pick the private key (id_rsa) or if there is some permission issue with .ssh or authorized_keys file. I am trying to find this in IPA environment as why this is happening for certain users only though it is picking the right private_key and client side. SSSD logs and secure logs does not have much to say except authentication failed. 3. I have checked the sshd config and does not seems to be an issue. KerberosAuthentication no PubkeyAuthentication yes UsePAM yes GSSAPIAuthentication yes AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys 4. As per the above slide, OpenSSH Integration with SSSD Slide 2 says, that add know_hosts file with SSSD, However, Neither IPA Client nor IPA Server has this Configure ssh in /etc/ssh/ssh_config Get known_hosts from SSSD GlobalKnownHostsFile /var/lib/sss/pubconf/known_hosts ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h A suggestion can really help us moving forward. *Best Regards,* *__* *Yogesh Sharma* *Email: yks0...@gmail.com yks0...@gmail.com | Web: www.initd.in http://www.initd.in/ * *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified* https://www.fb.com/yks http://in.linkedin.com/in/yks https://twitter.com/checkwithyogesh http://google.com/+YogeshSharmaOnGooglePlus -- 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] Dns SOA MNAME not resolving from LDAP data
On 08/20/2015 02:22 PM, Martin Basti wrote: On 08/20/2015 01:48 PM, David Dejaeghere wrote: Hi, I noticed that changing the authoritarive nameserver in FreeIPA reflects correctly to its directory data but bind will not resolve the soa record with the updated mname details. For example I add a zone test.be http://test.be and change the mname record. [root@ns02 ~]# ipa dnszone-add Zone name: test.be http://test.be Zone name: test.be http://test.be. Active zone: TRUE * Authoritative nameserver: ns02.tokiogroup.be http://ns02.tokiogroup.be.* Administrator e-mail address: hostmaster SOA serial: 1440070999 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant TOKIOGROUP.BE http://TOKIOGROUP.BE krb5-self * A; grant TOKIOGROUP.BE http://TOKIOGROUP.BE krb5-self * ; grant TOKIOGROUP.BE http://TOKIOGROUP.BE krb5-self * SSHFP; Dynamic update: FALSE Allow query: any; Allow transfer: none; [root@ns02 ~]# ipa dnszone-mod --nameserver anaconda-ks.cfg .bash_logout .bashrc .ipa/.ssh/ .bash_history.bash_profile.cshrc .pki/.tcshrc [root@ns02 ~]# ipa dnszone-mod --name-server*ns7.tokiogroup.be http://ns7.tokiogroup.be*. Zone name: test.be http://test.be ipa: WARNING: Semantic of setting Authoritative nameserver was changed. It is used only for setting the SOA MNAME attribute. NS record(s) can be edited in zone apex - '@'. Zone name: test.be http://test.be. Active zone: TRUE *Authoritative nameserver: ns7.tokiogroup.be http://ns7.tokiogroup.be.* Administrator e-mail address: hostmaster SOA serial: 1440071001 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Allow query: any; Allow transfer: none; [root@ns02 ~]# nslookup set q=SOA test.be http://test.be Server: 127.0.0.1 Address:127.0.0.1#53 test.be http://test.be *origin = ns02.tokiogroup.be http://ns02.tokiogroup.be* mail addr = hostmaster.test.be http://hostmaster.test.be serial = 1440071001 refresh = 3600 retry = 900 expire = 1209600 minimum = 3600 As you can see the SOA record still shows the original default value. Kind Regards, David Dejaeghere Thank you for this bug report. I opened bind-dyndb-ldap ticket https://fedorahosted.org/bind-dyndb-ldap/ticket/159 Martin I maybe found why do you have this issue, do you have fake_mname configured in bind_dyndb_ldap section of named.conf? If yes then remove this option to use SOA MNAME from LDAP. Martin -- 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] Dns SOA MNAME not resolving from LDAP data
The reason I hit this issue was because I am testing out a setup where ldap etc are running on a private subnet but is hosting public zones. Therefor I change the nameservers of these zones and the primary nameserver soa record to a public reachable hostname. I agree this is no issue for the majority of users. There already is a warning in the UI and IPA CLI. It might be good to add an extra line to this warning regarding the fake_mname, altought this might also cause confusion. Regards, David 2015-08-20 15:09 GMT+02:00 Martin Basti mba...@redhat.com: On 08/20/2015 02:46 PM, David Dejaeghere wrote: confirmed working. Does this default value make any sense if this value is changeable in the UI and using the IPA client? Kind Regards, David IMHO (I'm not 100% sure) IPA DNS are master servers, which contains only authoritative zones. Each DNS server contains the same copy of zones synchronized with LDAP database, and each server is authoritative for that zone (multimaster DNS topology). So there is no reason to have listed different server than IPA DNS as authoritative servers. This works for majority users. This also works as fallback (on local network only without caching) when one replica is down, the one of IPA DNS servers left, may act as authoritative servers (primary master for DDNS). I agree that this is tricky (I forgot about fake_mname too) for users who want to change it, we may show warning for user or somehow let him know that fake_mname is used. Martin 2015-08-20 14:38 GMT+02:00 Martin Basti mba...@redhat.com: On 08/20/2015 02:35 PM, David Dejaeghere wrote: Aha, Correct. But i never set this. This option seems to be set by default. I verified this issue on multiple installs. It seems they all have this option set by default? Can i safely change named.conf without fearing my modifications will be lost on an update? Kind Regards, David (Adding freeipa-users back) I checked code, it is default. You can change named.conf, upgrade will not replace it. Martin 2015-08-20 14:32 GMT+02:00 Martin Basti mba...@redhat.com mba...@redhat.com: On 08/20/2015 02:22 PM, Martin Basti wrote: On 08/20/2015 01:48 PM, David Dejaeghere wrote: Hi, I noticed that changing the authoritarive nameserver in FreeIPA reflects correctly to its directory data but bind will not resolve the soa record with the updated mname details. For example I add a zone test.be and change the mname record. [root@ns02 ~]# ipa dnszone-add Zone name: test.be Zone name: test.be. Active zone: TRUE * Authoritative nameserver: ns02.tokiogroup.be http://ns02.tokiogroup.be.* Administrator e-mail address: hostmaster SOA serial: 1440070999 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant TOKIOGROUP.BE krb5-self * A; grant TOKIOGROUP.BE krb5-self * ; grant TOKIOGROUP.BE krb5-self * SSHFP; Dynamic update: FALSE Allow query: any; Allow transfer: none; [root@ns02 ~]# ipa dnszone-mod --nameserver anaconda-ks.cfg .bash_logout .bashrc .ipa/.ssh/ .bash_history.bash_profile.cshrc .pki/ .tcshrc [root@ns02 ~]# ipa dnszone-mod --name-server* ns7.tokiogroup.be http://ns7.tokiogroup.be*. Zone name: test.be ipa: WARNING: Semantic of setting Authoritative nameserver was changed. It is used only for setting the SOA MNAME attribute. NS record(s) can be edited in zone apex - '@'. Zone name: test.be. Active zone: TRUE *Authoritative nameserver: ns7.tokiogroup.be http://ns7.tokiogroup.be.* Administrator e-mail address: hostmaster SOA serial: 1440071001 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Allow query: any; Allow transfer: none; [root@ns02 ~]# nslookup set q=SOA test.be Server: 127.0.0.1 Address:127.0.0.1#53 test.be * origin = ns02.tokiogroup.be http://ns02.tokiogroup.be* mail addr = hostmaster.test.be serial = 1440071001 refresh = 3600 retry = 900 expire = 1209600 minimum = 3600 As you can see the SOA record still shows the original default value. Kind Regards, David Dejaeghere Thank you for this bug report. I opened bind-dyndb-ldap ticket https://fedorahosted.org/bind-dyndb-ldap/ticket/159 https://fedorahosted.org/bind-dyndb-ldap/ticket/159 Martin I maybe found why do you have this issue, do you have fake_mname configured in bind_dyndb_ldap section of named.conf? If yes then remove this option to use SOA MNAME from LDAP. Martin -- 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] how to get directory services to listen on ipv4 interface?
Hello, I've been searching around trying to figure out about the ipv4 vs the ipv6 interfaces for a freeipa server. According to the instructions I see that: FreeIPA uses Samba as part of its Active Directory integration and Samba *requires enabled IPv6 stack* on the machine. Adding *ipv6.disable=1* to the kernel commandline disables the whole IPv6 stack and breaks Samba. Adding *ipv6.disable_ipv6=1* will keep the IPv6 stack functional but will not assign IPv6 addresses to any of your network devices. This is recommeneded approach for cases when you don't use IPv6 networking. I am only using ipv4 on our network. So I managed to set this up and this helped remove some of the services that were running on ipv6. I've configured freeipa server and can verify that the DNS part of the server is working as I can query it with DIG. I also notice this is working because bind is listening on the ipv4 and ipv6 interfaces. This is also true for sshd. It's on both interfaces so I can log in with ssh. I can even (locally on the ipa server) issue ldapsearch commands against the ldap database. The problem comes from when I try to add a client or query the server with ldap commands on another machine. What I suspect is that even though I disabled ipv6 it looks like the directory server is still ONLY listening to on the ipv6 interface as there isn't anything listed for ipv4. So I suspect this is why I can't query it remotely as it's only on ipv6. netstat -ln Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 0 127.0.0.1:8005 0.0.0.0:* LISTEN tcp0 0 127.0.0.1:8009 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:749 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:80800.0.0.0:* LISTEN tcp0 0 0.0.0.0:80 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:464 0.0.0.0:* LISTEN tcp0 0 PRIMARYIP:530.0.0.0:* LISTEN tcp0 0 127.0.0.1:530.0.0.0:* LISTEN tcp0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:88 0.0.0.0:* LISTEN tcp0 0 127.0.0.1:953 0.0.0.0:* LISTEN tcp0 0 127.0.0.1:250.0.0.0:* LISTEN tcp0 0 0.0.0.0:84430.0.0.0:* LISTEN tcp0 0 0.0.0.0:443 0.0.0.0:* LISTEN tcp6 0 0 :::389 :::*LISTEN tcp6 0 0 :::749 :::*LISTEN tcp6 0 0 :::464 :::*LISTEN tcp6 0 0 :::53 :::*LISTEN tcp6 0 0 :::22 :::*LISTEN tcp6 0 0 :::88 :::*LISTEN tcp6 0 0 :::636 :::*LISTEN udp0 0 PRIMARYIP:530.0.0.0:* udp0 0 127.0.0.1:530.0.0.0:* udp0 0 0.0.0.0:68 0.0.0.0:* udp0 0 0.0.0.0:88 0.0.0.0:* udp0 0 PRIMARYIP:123 0.0.0.0:* udp0 0 127.0.0.1:123 0.0.0.0:* udp0 0 0.0.0.0:123 0.0.0.0:* udp0 0 0.0.0.0:27861 0.0.0.0:* udp0 0 0.0.0.0:464 0.0.0.0:* udp6 0 0 :::53734:::* udp6 0 0 :::53 :::* udp6 0 0 :::123 :::* raw6 0 0 :::58 :::*7 This is a CentOS 7 box with freeipa-server-4.1.4-1.el7.centos.x86_64 installed. I tried to find possibly where there might be a setting to tell the 389 server to listen on ipv4 but I can't seem to figure out how to do that. Google searches aren't generally coming up with anything real useful either. Anyone have any idea's on what to do here? Thanks in advance! -Steve -- 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] Dns SOA MNAME not resolving from LDAP data
On 08/20/2015 03:14 PM, David Dejaeghere wrote: The reason I hit this issue was because I am testing out a setup where ldap etc are running on a private subnet but is hosting public zones. Therefor I change the nameservers of these zones and the primary nameserver soa record to a public reachable hostname. I agree this is no issue for the majority of users. There already is a warning in the UI and IPA CLI. It might be good to add an extra line to this warning regarding the fake_mname, altought this might also cause confusion. Regards, David I agree, ticket filed: https://fedorahosted.org/freeipa/ticket/5241 2015-08-20 15:09 GMT+02:00 Martin Basti mba...@redhat.com mailto:mba...@redhat.com: On 08/20/2015 02:46 PM, David Dejaeghere wrote: confirmed working. Does this default value make any sense if this value is changeable in the UI and using the IPA client? Kind Regards, David IMHO (I'm not 100% sure) IPA DNS are master servers, which contains only authoritative zones. Each DNS server contains the same copy of zones synchronized with LDAP database, and each server is authoritative for that zone (multimaster DNS topology). So there is no reason to have listed different server than IPA DNS as authoritative servers. This works for majority users. This also works as fallback (on local network only without caching) when one replica is down, the one of IPA DNS servers left, may act as authoritative servers (primary master for DDNS). I agree that this is tricky (I forgot about fake_mname too) for users who want to change it, we may show warning for user or somehow let him know that fake_mname is used. Martin 2015-08-20 14:38 GMT+02:00 Martin Basti mba...@redhat.com mailto:mba...@redhat.com: On 08/20/2015 02:35 PM, David Dejaeghere wrote: Aha, Correct. But i never set this. This option seems to be set by default. I verified this issue on multiple installs. It seems they all have this option set by default? Can i safely change named.conf without fearing my modifications will be lost on an update? Kind Regards, David (Adding freeipa-users back) I checked code, it is default. You can change named.conf, upgrade will not replace it. Martin 2015-08-20 14:32 GMT+02:00 Martin Basti mba...@redhat.com mailto:mba...@redhat.com: On 08/20/2015 02:22 PM, Martin Basti wrote: On 08/20/2015 01:48 PM, David Dejaeghere wrote: Hi, I noticed that changing the authoritarive nameserver in FreeIPA reflects correctly to its directory data but bind will not resolve the soa record with the updated mname details. For example I add a zone test.be http://test.be and change the mname record. [root@ns02 ~]# ipa dnszone-add Zone name: test.be http://test.be Zone name: test.be http://test.be. Active zone: TRUE *Authoritative nameserver: ns02.tokiogroup.be http://ns02.tokiogroup.be.* Administrator e-mail address: hostmaster SOA serial: 1440070999 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant TOKIOGROUP.BE http://TOKIOGROUP.BE krb5-self * A; grant TOKIOGROUP.BE http://TOKIOGROUP.BE krb5-self * ; grant TOKIOGROUP.BE http://TOKIOGROUP.BE krb5-self * SSHFP; Dynamic update: FALSE Allow query: any; Allow transfer: none; [root@ns02 ~]# ipa dnszone-mod --nameserver anaconda-ks.cfg .bash_logout .bashrc .ipa/ .ssh/ .bash_history .bash_profile .cshrc .pki/ .tcshrc [root@ns02 ~]# ipa dnszone-mod --name-server*ns7.tokiogroup.be http://ns7.tokiogroup.be*. Zone name: test.be http://test.be ipa: WARNING: Semantic of setting Authoritative nameserver was changed. It is used only for setting the SOA MNAME attribute. NS record(s) can be edited in zone apex - '@'. Zone name: test.be http://test.be. Active zone: TRUE *Authoritative nameserver: ns7.tokiogroup.be http://ns7.tokiogroup.be.* Administrator e-mail address: hostmaster SOA serial: 1440071001 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Allow query: any; Allow transfer: none; [root@ns02 ~]# nslookup set q=SOA test.be http://test.be Server: 127.0.0.1
Re: [Freeipa-users] Ubuntu Samba Server Auth against IPA
Hi Chris, Would be great to see! If I have it working and we have 2-3 testcases I think we can add it to the IPA docs! Keep me updated! Thanks Matt 2015-08-20 8:49 GMT+02:00 Christopher Lamb christopher.l...@ch.ibm.com: Matt Once I got Samba and FreeIPA integrated (by the good old extensions path), I always use FreeIPA to administer users. I have never tried the samba tools like smbpasswd. I still have a wiki how-to in the works, but I had to focus on some other issues for a while. Chris From: Matt . yamakasi@gmail.com To: Youenn PIOLET piole...@gmail.com Cc: Christopher Lamb/Switzerland/IBM@IBMCH, freeipa-users@redhat.com freeipa-users@redhat.com Date: 20.08.2015 08:12 Subject:Re: [Freeipa-users] Ubuntu Samba Server Auth against IPA HI Guys, Anyone still a working clue/test here ? I didn't came further as it seems there need to be some domain join / match following the freeipa devs. Thanks! Matt 2015-08-13 13:09 GMT+02:00 Matt . yamakasi@gmail.com: Hi, I might have found somthing which I already seen in the logs. I did a smbpasswd my username on the samba server, it connects to ldap very well. I give my new password and get the following: smbldap_search_ext: base = [dc=my,dc=domain], filter = [((objectClass=ipaNTGroupAttrs)(| (ipaNTSecurityIdentifier=S-1my--sid---)))], scope = [2] Attribute [displayName] not found. Could not retrieve 'displayName' attribute from cn=Default SMB Group,cn=groups,cn=accounts,dc=my,dc=domain Sid S-1my--sid--- - MYDOMAIN\Default SMB Group(2) So something is missing! Thanks so far guys! Cheers, Matt 2015-08-13 12:02 GMT+02:00 Matt . yamakasi@gmail.com: Hi Youenn, OK thanks! this takes me a little but futher now and I see some good stuff in my logging. I'm testing on a Windows 10 Machine which is not member of an AD or so, so that might be my issue for now ? When testing on the samba box itself as my user I get: [myusername@smb-01 ~]$ smbclient //smb-01.domain.local/shares ... Checking NTLMSSP password for MSP\myusername failed: NT_STATUS_WRONG_PASSWORD ... SPNEGO login failed: NT_STATUS_WRONG_PASSWORD Maybe I have an issue with encrypted passwords ? When we have this all working, I think we have a howto :D Thanks! Matt 2015-08-13 10:53 GMT+02:00 Youenn PIOLET piole...@gmail.com: Hi Matt - CentOS : Did you copy ipasam.so and change your smb.conf accordingly? sambaSamAccount is not needed anymore that way. - Default IPA Way : won't work if your Windows is not part of a domain controller. DOMAIN\username may work for some users using Windows 7 - not 8 nor 10 (it did for me but I was the only one at the office... quite useless) This config may work on your CentOS (for the ipasam way): workgroup = TEST realm = TEST.NET kerberos method = dedicated keytab dedicated keytab file = FILE:/./samba.keytab create krb5 conf = no security = user encrypt passwords = true passdb backend = ipasam:ldaps://youripa.test.net ldapsam:trusted = yes ldapsuffix = test.net ldap user suffix = cn=users,cn=accounts ldap group suffix = cn=groups,cn=accounts -- Youenn Piolet piole...@gmail.com 2015-08-12 22:15 GMT+02:00 Matt . yamakasi@gmail.com: Hi, OK the default IPA way works great actually when testing it as described here: http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA On the samba server I can auth and see my share where I want to connect to. The issue is, on Windows I cannot auth, even when I do DOMAIN\username as username So, the IPA way should work. Any comments here ? Cheers, Matt 2015-08-12 19:00 GMT+02:00 Matt . yamakasi@gmail.com: HI GUys, I'm testing this out and I think I almost setup, this on a CentOS samba server. I'm using the ipa-adtrust way of Youeen but it seems we still need to add (objectclass=sambaSamAccount)) ? Info is welcome! I will report back when I have it working. Thanks! Matt 2015-08-10 11:16 GMT+02:00 Christopher Lamb christopher.l...@ch.ibm.com: The next route I will try - is the one Youeen took, using ipa-adtrust From: Matt . yamakasi@gmail.com To: Christopher Lamb/Switzerland/IBM@IBMCH, freeipa-users@redhat.com freeipa-users@redhat.com Date: 10.08.2015 10:03 Subject:Re: [Freeipa-users] Ubuntu Samba Server Auth against IPA Hi Chris, Okay this is good to hear. But don't we want a IPA managed Scheme ? When I did a ipa-adtrust-install --add-sids it also wanted a local installed Samba and I wonder why. Good that we make some progres on making it all clear. Cheers, Matt 2015-08-10 6:12 GMT+02:00 Christopher Lamb christopher.l...@ch.ibm.com: ldapsam + the samba extensions, pretty much as described in the Techslaves article. Once I have a draft for the wiki page, I will mail you. From: Matt .
[Freeipa-users] Users can't login on some systems.
Hi List, I'm still fairly new to this list and administrating FreeIPA. I had a very old version of freeipa and had all sorts of odd issues with it. I had 47 ubuntu clients attached to the domain. I setup a newer freeipa server version: 4.1.4 I recreated all my user accounts by hand I did not migrate any of them. I then removed the 47 clients from the old domain #ipa-client-install --uninstall Then I reinstalled each client #ipa-client-install --domain=cs.oberlin.edu --realm=CS.OBERLIN.EDU -p admin -W --hostname `hostname` -N it finished without errors on all my systems. two of my systems will not let any ipa users login via ssh or the console. the rest of them work fine. After keying in the password I get the following. Permission denied, please try again. id (username) shows the UID and GID and Groups correctly. getent passwd shows only my local accounts I don't have enumerate on. kinit also works. _my auth.log shows this_ pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=132.162.201.237 user=HIDDEN pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=132.162.201.237 user=HIDDEN pam_sss(sshd:auth): received for user : 7 (Authentication failure) I know it's the correct password as it works on the other clients. _I get this in krb5_child.log_ [[sssd[krb5_child[10546 [unpack_buffer] (0x0100): cmd [241] uid [66133] gid [100] validate [true] enterprise principal [false] offline [false] UPN [@CS.OBERLIN.EDU] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_66133_XX] keytab: [/etc/krb5.keytab] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/occs.cs.oberlin@cs.oberlin.edu] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [match_principal] (0x1000): Principal matched to the sample (host/occs.cs.oberlin@cs.oberlin.edu). (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [check_fast_ccache] (0x0200): FAST TGT is still valid. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [main] (0x0400): Will perform online auth (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [tgt_req_child] (0x1000): Attempting to get a TGT (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [get_and_save_tgt] (0x0400): Attempting kinit for realm [CS.OBERLIN.EDU] (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [validate_tgt] (0x0400): TGT verified using key for [host/occs.cs.oberlin@cs.oberlin.edu]. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [become_user] (0x0200): Trying to become user [66133][100]. (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [k5c_send_data] (0x0200): Received error code 0 (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [main] (0x0400): krb5_child completed successfully (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [main] (0x0400): krb5_child started. (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [unpack_buffer] (0x1000): total buffer size: [127] (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [unpack_buffer] (0x0100): cmd [241] uid [66133] gid [100] validate [true] enterprise principal [false] offline [false] UPN [@CS.OBERLIN.EDU] _sssd.conf on the broken machine_ [domain/cs.oberlin.edu] debug_level=8 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = cs.oberlin.edu id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = occs.cs.oberlin.edu chpass_provider = ipa ipa_server = _srv_, ipa1.cs.oberlin.edu ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam, ssh config_file_version = 2 debug_level=8 domains = cs.oberlin.edu [nss] debug_level=8 [pam] debug_level=8 [sudo] [autofs] [ssh] debug_level=8 [pac] _The broken systems sssd_nss.log _[nss_cmd_getpwnam_search] (0x0400): Returning info for user [hid...@cs.oberlin.edu] [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [17] with input [HIDDEN]. [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'HIDDEN' matched without domain, user is HIDDEN [sssd[nss]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [HIDDEN] from [ALL] [sssd[nss]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/cs.oberlin.edu/HIDDEN] [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [hid...@cs.oberlin.edu] [sssd[nss]] [check_cache] (0x0400): Cached
Re: [Freeipa-users] Ubuntu Samba Server Auth against IPA
Matt Once I got Samba and FreeIPA integrated (by the good old extensions path), I always use FreeIPA to administer users. I have never tried the samba tools like smbpasswd. I still have a wiki how-to in the works, but I had to focus on some other issues for a while. Chris From: Matt . yamakasi@gmail.com To: Youenn PIOLET piole...@gmail.com Cc: Christopher Lamb/Switzerland/IBM@IBMCH, freeipa-users@redhat.com freeipa-users@redhat.com Date: 20.08.2015 08:12 Subject:Re: [Freeipa-users] Ubuntu Samba Server Auth against IPA HI Guys, Anyone still a working clue/test here ? I didn't came further as it seems there need to be some domain join / match following the freeipa devs. Thanks! Matt 2015-08-13 13:09 GMT+02:00 Matt . yamakasi@gmail.com: Hi, I might have found somthing which I already seen in the logs. I did a smbpasswd my username on the samba server, it connects to ldap very well. I give my new password and get the following: smbldap_search_ext: base = [dc=my,dc=domain], filter = [((objectClass=ipaNTGroupAttrs)(| (ipaNTSecurityIdentifier=S-1my--sid---)))], scope = [2] Attribute [displayName] not found. Could not retrieve 'displayName' attribute from cn=Default SMB Group,cn=groups,cn=accounts,dc=my,dc=domain Sid S-1my--sid--- - MYDOMAIN\Default SMB Group(2) So something is missing! Thanks so far guys! Cheers, Matt 2015-08-13 12:02 GMT+02:00 Matt . yamakasi@gmail.com: Hi Youenn, OK thanks! this takes me a little but futher now and I see some good stuff in my logging. I'm testing on a Windows 10 Machine which is not member of an AD or so, so that might be my issue for now ? When testing on the samba box itself as my user I get: [myusername@smb-01 ~]$ smbclient //smb-01.domain.local/shares ... Checking NTLMSSP password for MSP\myusername failed: NT_STATUS_WRONG_PASSWORD ... SPNEGO login failed: NT_STATUS_WRONG_PASSWORD Maybe I have an issue with encrypted passwords ? When we have this all working, I think we have a howto :D Thanks! Matt 2015-08-13 10:53 GMT+02:00 Youenn PIOLET piole...@gmail.com: Hi Matt - CentOS : Did you copy ipasam.so and change your smb.conf accordingly? sambaSamAccount is not needed anymore that way. - Default IPA Way : won't work if your Windows is not part of a domain controller. DOMAIN\username may work for some users using Windows 7 - not 8 nor 10 (it did for me but I was the only one at the office... quite useless) This config may work on your CentOS (for the ipasam way): workgroup = TEST realm = TEST.NET kerberos method = dedicated keytab dedicated keytab file = FILE:/./samba.keytab create krb5 conf = no security = user encrypt passwords = true passdb backend = ipasam:ldaps://youripa.test.net ldapsam:trusted = yes ldapsuffix = test.net ldap user suffix = cn=users,cn=accounts ldap group suffix = cn=groups,cn=accounts -- Youenn Piolet piole...@gmail.com 2015-08-12 22:15 GMT+02:00 Matt . yamakasi@gmail.com: Hi, OK the default IPA way works great actually when testing it as described here: http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA On the samba server I can auth and see my share where I want to connect to. The issue is, on Windows I cannot auth, even when I do DOMAIN\username as username So, the IPA way should work. Any comments here ? Cheers, Matt 2015-08-12 19:00 GMT+02:00 Matt . yamakasi@gmail.com: HI GUys, I'm testing this out and I think I almost setup, this on a CentOS samba server. I'm using the ipa-adtrust way of Youeen but it seems we still need to add (objectclass=sambaSamAccount)) ? Info is welcome! I will report back when I have it working. Thanks! Matt 2015-08-10 11:16 GMT+02:00 Christopher Lamb christopher.l...@ch.ibm.com: The next route I will try - is the one Youeen took, using ipa-adtrust From: Matt . yamakasi@gmail.com To: Christopher Lamb/Switzerland/IBM@IBMCH, freeipa-users@redhat.com freeipa-users@redhat.com Date: 10.08.2015 10:03 Subject:Re: [Freeipa-users] Ubuntu Samba Server Auth against IPA Hi Chris, Okay this is good to hear. But don't we want a IPA managed Scheme ? When I did a ipa-adtrust-install --add-sids it also wanted a local installed Samba and I wonder why. Good that we make some progres on making it all clear. Cheers, Matt 2015-08-10 6:12 GMT+02:00 Christopher Lamb christopher.l...@ch.ibm.com: ldapsam + the samba extensions, pretty much as described in the Techslaves article. Once I have a draft for the wiki page, I will mail you. From: Matt . yamakasi@gmail.com To: Christopher Lamb/Switzerland/IBM@IBMCH, freeipa-users@redhat.com freeipa-users@redhat.com Date: 09.08.2015 21:17 Subject:Re: [Freeipa-users] Ubuntu Samba Server Auth against IPA Hi, Yes I
