Re: [Freeipa-users] Apple OpenDirectory Integration

[Mauricio Tavares]

I have a few Macs with 10.7 (mini) and 10.9 (MB air). Let me know if I
can help using them as guinea piggies

On Thu, Feb 4, 2016 at 11:57 AM, Alexander Bokovoy  wrote:
> On Thu, 04 Feb 2016, "Răzvan Corneliu C.R. VILT" wrote:
>>
>>
 It's static data. It's a concatenation of multiple strings: a
 hard-coded one, the uid and the realm. It only changes if you rename
 the user account. It is used to route the authn phase to the Kerberos
 account (no PAM configuration!!!).
>>>
>>> I wonder if we should use CoS plugin to get this data added to user
>>> entries instead of storing it in every single user's LDAP entry -- the
>>> only thing that is different is uid but the rest is the same, right?
>>
>>
>> Right. At least for single realms with no trust domains. If you have an
>> identity from another realm, you need to use the KRB5 principal from
>> that realm. So instead of mapping to the UID, we should map to the
>> krbPrincipal.
>
> Yep.
>
> I've moved the ticket 4813 to needs triage basket and referenced this
> thread.
>
>
>>
>> The format for altSecurityIdentities is:
>> ===
>> "Kerberos:" + $krbPrincipal
>> Or for certificate logon:
>> "X509:" + "CN=" + $issuerRDN + "CN=" + $subject. Such as:
>> "X509:CN=Apple Root CA,OU=Apple Certification Authority,O=Apple
>> Inc.,C=USCN=com.apple.idms.appleid.prd.deadbeefdeadbeefdeadbeefdeadbeef"
>>
>> It's identical to the altSecurityIdentities from MSDN and was adopted by
>> Apple from Microsoft. See
>> https://msdn.microsoft.com/en-us/library/cc220106.aspx
>> In theory it can also be used for SC Certificate logons (see above
>> example). It is also used by iCloud for certificate logons.
>>
>>
>> The format for authAuthority is:
>> =
>> Kerberos
>> 
>> Minimal Kerberos:
>> ";Kerberosv5;;" + $krbPrincipal + ";" + $realm + ";"
>>
>> Fully compliant Kerberos:
>> ";Kerberosv5;" + "0x"$GUID_HEX + ";" + $krbPrincipal + ";" + $realm + ";"
>> + "Realm Public Key"
>> Documented on:
>> https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP4917-CH3-68599
>>
>> Basic Authentication
>> 
>> Of no interest, just crypt(). Documented on:
>>
>> https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP4917-CH3-68270
>>
>> Apple Password Server Authentication:
>> -
>> ;ApplePasswordServer;0xfc001e291a400254ba69508,1024 65537
>> 1073536022652669667510124737971525265977003458292838259662475941942339637701783031842665637489899899968013535474647377427038990743911664412758698759306606987798849786426049586039725915353359580583450027978985802381494661566820916379229460639580871881869418576860074704243214464804408968770344748232621
>> r...@ipa.example.com:172.23.36.138
>> Documented on:
>> https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP4917-CH3-68312
>> Partly implemented in https://code.google.com/archive/p/lpws but without
>> an IPA Bridge.
>>
>> Shadow Hash Authentication (used by local accounts):
>> 
>> ;ShadowHash;HASHLIST:
>> Documented on:
>>
>> https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP4917-CH3-68474
>>
>> Local Cached User Authentication (used by road-warrior scenarios on the
>> local systems):
>>
>> ---
>> Documented on:
>>
>> https://developer.apple.com/library/mac/documentation/Networking/Conceptual/Open_Directory/openDirectoryConcepts/openDirectoryConcepts.html#//apple_ref/doc/uid/TP4917-CH3-68528
>>
>> Netlogon Authentication (used by Active Directory)
>> --
>> ;Netlogon;razvan.vilt;MYDOMAIN
>>
>> iCloud Authentication (obvious)
>> ---
>> ;AppleID;razvan.v...@me.com
>>
>> Disabled Authentication (this needs attention)
>> --
>> Basically put ";DisabledUser;;" in front of the previous authentication
>> method.
>>
>>
 OK. So on Linux you do an automount map for the file server with the
 homes and state that the user home directory is in /home/$userName

 On Windows, you give the home folder as \\server\share\folder, but
 assume that the protocol is SMB/CIFS.

 On Mac OS X, you give the protocol, the server and the share\folder.
 You could use automount, but I've never seen any OS X admin do that.

Re: [Freeipa-users] FreeIPA WebUI Logout logs back in

[Mauricio Tavares]

On Apr 28, 2015 11:33 PM, Dmitri Pal d...@redhat.com wrote:

 On 04/28/2015 05:11 PM, Christopher Lamb wrote:

 HI All

 I have just tested with the FreeIPA Web UI public demo
 https://ipa.demo1.freeipa.org/ipa/ui/

 Using the public demo, when I log out, I get returned to the login
screen,
 as expected. This allows me to log in with a different user.

 With our own installation FreeIPA, from exactly the same browser, I get
 logged straight back in to the Web UI - which makes logging out
pointless.

 still confused ...


 Do you have a kerberos ticket on your local system?
 Do klist.
 See which tickets you have.
 If you have tickets do kdestroy - this will remove the ability to SSO. If
you then try to use your IPA server you will have the same experience as
with public demo.

  I think the user case Chris is alluding is

1. Login to your desktop as you
2. Login then to IPA server as an admin user that has nothing to do with
your everyday user account.
3. Rinse and repeat

 Chris



 From:   Dmitri Pal d...@redhat.com
 To: freeipa-users@redhat.com
 Date:   27.04.2015 21:31
 Subject:Re: [Freeipa-users] FreeIPA WebUI Logout logs back in
 Sent by:freeipa-users-boun...@redhat.com



 On 04/27/2015 12:39 PM, Christopher Lamb wrote:

 Hi All

 When I use the logout dropdown the WebUI (top righthand corner of the
 screen), it logs me out, then immediately reloads and logs me right back

 in

 again to the Users screen.

 This prevents me from logging in with a different user.

 The FreeIPA Server is 4.1.0 on OEL 7.5.

 I am using Web UI from an OSX workstation (Firefox and Safari).

 We did not have this behaviour with FreeIPA 3.0.0

 Thanks for your help

 Chris

 Try kdestroy and then logout.
 I am not sure it worked differently in 3.0 may be you tried 3.0 when
 your Kerberis ticket already expired.

 --
 Thank you,
 Dmitri Pal

 Sr. Engineering Manager IdM portfolio
 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






 --
 Thank you,
 Dmitri Pal

 Sr. Engineering Manager IdM portfolio
 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
-- 
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] Could not chdir to home directory /home/net/dean: Permission denied

[Mauricio Tavares]

On Mon, Apr 21, 2014 at 3:05 PM, Dean Hunter deanhun...@comcast.net wrote:
 I am sorry, but I have forgotten where to start to diagnose this problem.
 Please remind me.

 [dean@host ~]$ ssh desktop.hunter.org
 Last login: Sun Apr 20 21:12:38 2014 from host.hunter.org
 Could not chdir to home directory /home/net/dean: Permission denied
 -bash: /home/net/dean/.bash_profile: Permission denied
 -bash-4.2$ pwd
 /
 -bash-4.2$ ls -l /home
 total 4
 drwx--. 4 local local 4096 Apr 20 21:04 local
 drwxr-xr-x. 3 root  root 0 Apr 21 13:48 net
 -bash-4.2$ ls -l /home/net
 total 8
 drwx--x---. 29 dean dean 4096 Apr 20 21:28 dean
 -bash-4.2$ ls -l /home/net/dean
 ls: cannot access /home/net/dean: Permission denied
 -bash-4.2$ whoami
 dean
 -bash-4.2$ exit
 logout
 -bash: /home/net/dean/.bash_logout: Permission denied
 Connection to desktop.hunter.org closed.
 [dean@host ~]$

 desktop.hunter.org is a VM that I have rebuilt several times trying to work
 around this problem. ipa-client-install and  ipa-client-automount completed
 without error messages.  /home/net/dean is accessible when I log-in through
 gdm and Virtual Machine Manager.

  If you were using pam, I would say the config for when you ssh
in is different than that for when you use gdm. Specifically it is not
getting creating a cache file when you log in.


 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] On ipadiscovery.py

[Mauricio Tavares]

  Trying to understand the class IPADiscovery and why it does not
like my ubuntu64 box and my network:

1. We start with

root@ubuntu64:~# ipa-client-install
DNS discovery failed to determine your DNS domain
Provide the domain name of your IPA server (ex: example.com):

I take most of the hot action is happening in ipadiscovery.py. Am I
correct to assume that check_domain is looking for lines that contain
domain in them? Mine looks like this:

root@ubuntu64:~# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.0.0.1
search in.domain.com
root@ubuntu64:~#

which would (I hope) explain the following entries in the log file:

2014-02-25 23:41:05,995 DEBUG [ipadnssearchldap(in.domain.com)]
2014-02-25 23:41:05,995 DEBUG [ipadnssearchldap(domain.com)]
2014-02-25 23:41:05,995 DEBUG [ipadnssearchldap(com)]
2014-02-25 23:41:05,995 DEBUG [ipadnssearchldap(in.domain.com)]
2014-02-25 23:41:05,995 DEBUG [ipadnssearchldap(domain.com)]
2014-02-25 23:41:05,996 DEBUG [ipadnssearchldap(com)]
2014-02-25 23:41:05,996 DEBUG Domain not found

2. In ipadnssearchldap, are the lines

qname = _ldap._tcp.+tdomain
# terminate the name
if not qname.endswith(.):
qname += .
results = ipapython.dnsclient.query(qname,
ipapython.dnsclient.DNS_C_IN, ipapython.dnsclient.DNS_T_SRV)

supposed to do something like

root@ubuntu64:~# dig +short _ldap._tcp.in.domain.com SRV
0 0 389 auth.in.domain.com.
root@ubuntu64:~#

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Trying to use the CLI logs me out

[Mauricio Tavares]

On Fri, Feb 21, 2014 at 1:36 PM, Rob Crittenden rcrit...@redhat.com wrote:
 Bret Wortman wrote:

 I'm getting ready to leave for the weekend, and this isn't the kind of
 thing I want to track down on a Friday, but if anyone has any ideas for
 things I should look at come Monday morning, I'd be very appreciative.

 I've got a system with 12 replicas, and no matter which IPA server I log
 into and try to run ipa CLI commands on (even ipa help), I get my
 session terminated. I also tried from a client system that has the
 ipatools rpm installed, and in that case I got bounced out of my sudo'd
 root session.

 I need to figure this out because something's obviously amiss, and we
 have discovered a number of systems that are lacking Kerberos keys. I
 was hoping the CLI would provide the mechanism to get them fixed. We're
 also trying to track down a 6-10 second delay every time a user logs in
 using SSSD to authenticate; the password check passes almost instantly,
 but something is taking up an additional bunch of time and my users are
 starting to complain. So I need to get past this so I can debug that.

 Thanks, and have a great weekend, all.


 For the life of me I can't figure out what the ipa command might do that
 would log you out. I think brute force might be a way to go with this:

 strace -f o /tmp/out ipa help

 Then go back in and see what happened.

 As for login delay you may want to pick a client system and bump up the sssd
 debug level and see if that provides any clues.

  I would also run ldapsearch in the client after you manually
kinit'ed, to see which part of the show is boink.

 rob


 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Trying to use the CLI logs me out

[Mauricio Tavares]

On Fri, Feb 21, 2014 at 2:05 PM, Bret Wortman
bret.wort...@damascusgrp.com wrote:
 Bizarre.

 # strace -f -o /tmp/out ipa help

 Usage: ipa [global-options] COMMAND [command-options]

 :

 :

 :


 # ipa help

 Connection to ipamaster closed.

 $

  When you logged back in, did /tmp/out have anything interesting?



 On 02/21/2014 01:36 PM, Rob Crittenden wrote:

 Bret Wortman wrote:

 I'm getting ready to leave for the weekend, and this isn't the kind of
 thing I want to track down on a Friday, but if anyone has any ideas for
 things I should look at come Monday morning, I'd be very appreciative.

 I've got a system with 12 replicas, and no matter which IPA server I log
 into and try to run ipa CLI commands on (even ipa help), I get my
 session terminated. I also tried from a client system that has the
 ipatools rpm installed, and in that case I got bounced out of my sudo'd
 root session.

 I need to figure this out because something's obviously amiss, and we
 have discovered a number of systems that are lacking Kerberos keys. I
 was hoping the CLI would provide the mechanism to get them fixed. We're
 also trying to track down a 6-10 second delay every time a user logs in
 using SSSD to authenticate; the password check passes almost instantly,
 but something is taking up an additional bunch of time and my users are
 starting to complain. So I need to get past this so I can debug that.

 Thanks, and have a great weekend, all.


 For the life of me I can't figure out what the ipa command might do that
 would log you out. I think brute force might be a way to go with this:

 strace -f o /tmp/out ipa help

 Then go back in and see what happened.

 As for login delay you may want to pick a client system and bump up the
 sssd debug level and see if that provides any clues.

 rob




 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

[Freeipa-users] Windows client

[Mauricio Tavares]

  When I added a windows 7 client (let's call it
windows.lan.domain.com), I had to go manually enter the domain (in
System Properties-Computer Name/Domain Changes-DNS Suffix and
netbios computer name) even though ipconfig would report it properly.
Otherwise, it would show in the kdc log file as windows$@DOMAIN.COM
instead of windows.lan.domain@domain.com. Does anyone know why? I
know the realm and the domain names are not quite the same (domain has
a lan in it), but should that matter?

  On an unrelated note, in
http://www.freeipa.org/page/Windows_authentication_against_FreeIPA it
should be

ksetup /addkpasswd

not

ksetup /addkpassword

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Windows client

[Mauricio Tavares]

On Wed, Feb 19, 2014 at 2:02 PM, Petr Spacek pspa...@redhat.com wrote:
 On 19.2.2014 19:44, Simo Sorce wrote:

 On Wed, 2014-02-19 at 20:34 +0200, Alexander Bokovoy wrote:

 On Wed, 19 Feb 2014, Mauricio Tavares wrote:

   When I added a windows 7 client (let's call it
 windows.lan.domain.com), I had to go manually enter the domain (in
 System Properties-Computer Name/Domain Changes-DNS Suffix and
 netbios computer name) even though ipconfig would report it properly.
 Otherwise, it would show in the kdc log file as windows$@DOMAIN.COM
 instead of windows.lan.domain@domain.com. Does anyone know why? I
 know the realm and the domain names are not quite the same (domain has
 a lan in it), but should that matter?

 Windows uses NetBIOS name$ as the machine name in TGT requests for the
 host.

 At this point we don't have means to correct this via IPA CLI. You need
 to use ldapmodify directly and add

  krbprincipalname: windows$DOMAIN.COM
  krbcanonicalname: HOST/windows.lan.domain@domain.com


 Note that 'host' here should be lower case.


 ... And please note that
 http://www.freeipa.org/page/Windows_authentication_against_FreeIPA is an
 option of last resort.

 Please use real trust between AD and IPA whenever possible:
 http://www.freeipa.org/page/Trusts

  Would not having an AD server be eligible for the option of last resort?

 Have a nice day!

 Petr^2 Spacek


 to the host entry.

 KrbPrincipalName can have multiple values and if there are more than
 one, KrbCanonicalName should be set to the canonical version which is
 the original KrbPrincipalName in IPA.


   On an unrelated note, in
 http://www.freeipa.org/page/Windows_authentication_against_FreeIPA it
 should be

 ksetup /addkpasswd

 not

 ksetup /addkpassword

 Corrected, thanks!


 ___
 Freeipa-users mailing list
 Freeipa-users@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-users

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] ipa-client-install does not seem to like the ipa's ntp

[Mauricio Tavares]

On Feb 11, 2014 4:12 AM, Martin Kosek mko...@redhat.com wrote:

 On 02/10/2014 10:08 PM, Mauricio Tavares wrote:
  On Mon, Feb 10, 2014 at 3:40 PM, Dmitri Pal d...@redhat.com wrote:
  On 02/09/2014 09:52 PM, Mauricio Tavares wrote:
 
  On Sun, Feb 9, 2014 at 9:07 PM, Steve Dainardsdain...@miovision.com
  wrote:
 
  I've noticed if ntpd is already running on the client when you run
the
  ipa-client-install, you will get that error. I'm guessing its using
  ntpdate
  IP ADDRESS to sync time, and cannot do so when the daemon is running.
 
  I've noticed if ntpd is already running on the client when you run
the
  ipa-client-install, you will get that error. I'm guessing its using
  ntpdate
  IP ADDRESS to sync time, and cannot do so when the daemon is running.
 
 Now that you mentioned that I would agree with you in that it
is
  failing because ntpd is running already; I could not see it because of
  the option -s in
 
  [root@centos64 ~]# service ntpd status
  ntpd (pid  3721) is running...
  [root@centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v
auth.in.domain.com
  [root@centos64 ~]#
 
  I could not find what all of those arguments mean in the centos 6.5
  ntpdate man page, but here is what I found under ubuntu's:
 
  -b Force  the  time  to  be stepped using the
settimeofday()
  system
 call, rather than slewed (default) using  the
 adjtime()
  system
 call. This option should be used when called from a
startup
  file
 at boot time.
 
  -s Divert logging output from the standard output
(default) to
  the
 system  syslog  facility.  This is designed primarily
for
  conve‐
 nience of cron scripts.
 
  -v Be verbose. This option will cause ntpdate's version
  identifica‐
 tion string to be logged.
 
  In other words, -s is sending the output to syslog. And, if we check
  /var/log/messages we will find that
 
  Feb  9 21:17:06 centos64 ntpdate[8275]: the NTP socket is in use,
exiting
 
  as you expected. Now, how did it detect the ntpdate failed?
 
  Steve
 
 
  On Sat, Feb 8, 2014 at 8:34 AM, Mauricio Tavaresraubvo...@gmail.com
  wrote:
 
 Even though I already have a ntp server, I setup my newly
  created freeipa kdc to do that too (it is a slave to my primary
ntp).
 
  I then build a centos host to be the test client. Just to make sure
it
  can see and use auth's ntp, I tested with ntpdate:
 
  [root@centos64 ~]# ntpdate auth
8 Feb 08:13:35 ntpdate[3251]: adjust time server 10.0.0.11 offset
  -0.003097 sec
  [root@centos64 ~]#
 
  so far so good, so how about running ipa-client-install?
 
  [root@centos64 ~]# hostname
  centos64
  [root@centos64 ~]# ipa-client-install --hostname=`hostname -f`
  Discovery was successful!
  Hostname: centos64.in.domain.com
  Realm: DOMAIN.COM
  DNS Domain: domain.com
  IPA Server: auth.in.domain.com
  BaseDN: dc=domain,dc=com
 
  [so far so good!]
 
  Continue to configure the system with these values? [no]: yes
  User authorized to enroll computers: admin
  Synchronizing time with KDC...
  Unable to sync time with IPA NTP server, assuming the time is in
sync.
  Please check that 123 UDP port is opened.
  Password for ad...@domain.com:
 
  But, it had not problems using ntpdate against auth.  to add insult
to
  injury, the log claims it is using ntpdate:
 
  2014-02-08T13:14:31Z DEBUG args=/usr/sbin/ntpdate -U ntp -s -b -v
  auth.in.domain.com
  2014-02-08T13:14:31Z DEBUG stdout=
  2014-02-08T13:14:31Z DEBUG stderr=
  2014-02-08T13:14:31Z WARNING Unable to sync time with IPA NTP
server,
  assuming the time is in sync. Please check that 123 UDP port is
  opened.
 
  Could it be it is pissed because it was in sync to begin with? I
mean,
  if we run the exact command the log file claims to have run,
 
  [root@centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v
auth.in.domain.com|
  echo $?
  0
  [root@centos64 ~]#
 
  We see it was successful.
 
  I am feeling rather clueless here...
 
  ___
  Freeipa-users mailing list
  Freeipa-users@redhat.com
  https://www.redhat.com/mailman/listinfo/freeipa-users
 
 
  ___
  Freeipa-users mailing list
  Freeipa-users@redhat.com
  https://www.redhat.com/mailman/listinfo/freeipa-users
 
 
  This sounds like a bug to me but I would wait for European gurus to
chime in
  the morning.
  If it is a bug we need a ticket.
 
I dunno where to file a ticket but here is my suggestion:
 
  in /usr/lib/python2.6/site-packages/ipaclient/ntpconf.py, function def
  synconce_ntp(server_fqdn):
 
  replace
 
  cmd = [ntpdate, -U, ntp, -s, -b, -v, server_fqdn]
 
  with
 
  cmd = [ntpdate, -U, ntp, -s, -b, -v, -u,
server_fqdn]
 
  Reasoning:
 
  [root@centos64 ~]# date +%T -s 10:13:13
  10:13:13
  [root@centos64 ~]# date
  Mon Feb 10 10:13:15 EST 2014
  [root@centos64 ~]# /usr/sbin/ntpdate -U ntp -s -b -v -u

[Freeipa-users] Specifying gid/uid range

[Mauricio Tavares]

  Where can I configure the range, or at least starting value, for
the uid and gid that will be used when creating user accounts?

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users