I upgraded A windows host from windows 10 to windows 11, and of course i could no longer authenticate.

Samba logs showed

[2022/10/02 15:48:24.186783,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: ENC-TS Pre-authentication succeeded -- Administrator@DOMAIN] using aes256-cts-hmac-sha1-96
[2022/10/02 15:48:24.186919,  3] ../../auth/auth_log.c:635(log_authentication_event_human_readable)
  Auth: [Kerberos KDC,ENC-TS Pre-authentication] user [(null)]\[Administrator@DOMAIN] at [Sun, 02 Oct 2022 15:48:24.186874 CEST] with [aes256-cts-hmac-sha1-96] status [NT_STATUS_OK] workstation [(
null)] remote host [ipv4:192.168.50.47:59182] became [DOMAIN]]\[Administrator] [S-1-5-21-3293602716-1359220633-1131700490-500]. local host [NULL] 
  {"timestamp": "2022-10-02T15:48:24.187054+0200", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 2}, "eventId": 4624, "logonId": "3be75b668c8b39de", "logonType": 3, "statu
s": "NT_STATUS_OK", "localAddress": null, "remoteAddress": "ipv4:192.168.50.47:59182", "serviceDescription": "Kerberos KDC", "authDescription": "ENC-TS Pre-authentication", "clientDomain": null, "clientA
ccount": "Administrator@DOMAIN]", "workstation": null, "becameAccount": "Administrator", "becameDomain": "DOMAIN]", "becameSid": "S-1-5-21-3293602716-1359220633-1131700490-500", "mappedAccount": "Ad
ministrator", "mappedDomain": "DOMAIN", "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "p
asswordType": "aes256-cts-hmac-sha1-96", "duration": 10444}}
[2022/10/02 15:48:24.280991,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: AS-REQ authtime: 2022-10-02T15:48:24 starttime: unset endtime: 2022-10-03T01:48:24 renew till: 2022-10-09T15:48:24
[2022/10/02 15:48:24.281140,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Client supported enctypes: aes256-cts-hmac-sha1-96, arcfour-hmac-md5, -133, -128, 24, -135, using aes256-cts-hmac-sha1-96/aes256-cts-hmac-sha1-96
[2022/10/02 15:48:24.281273,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Requested flags: renewable-ok, canonicalize, renewable, forwardable
[2022/10/02 15:48:24.285839,  3] ../../source4/smbd/service_stream.c:67(stream_terminate_connection)
  stream_terminate_connection: Terminating connection - 'kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED'
[2022/10/02 15:48:24.293498,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Failed to verify authenticator checksum: Decrypt integrity check failed for checksum type rsa-md5, key type aes256-cts-hmac-sha1-96
[2022/10/02 15:48:24.293619,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Failed parsing TGS-REQ from ipv4:192.168.50.47:59183
[2022/10/02 15:48:24.297725,  3] ../../source4/smbd/service_stream.c:67(stream_terminate_connection)
  stream_terminate_connection: Terminating connection - 'kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED'
[2022/10/02 15:49:29.696239,  3] ../../source4/lib/socket/interface.c:91(add_interface)

I know NTLM /SMB1 is now disabled by default in windows 11, but i could not figure out how thats related.

in the end i found:

Cannot connect to Samba AD DC on Windows 11 Dev from windowsinsiders

The fast solution is

Local Security Policy> Local Policies> Security Options> Network security: Configure encryption types allowed for Kerberos Check only DES_CBC_CRC and DES_CBC_MD5

Apparently samba 4.16 also fixes it. But its not hit stable yet for debian.

Microsoft have been ramping up the security of their endpoints and its getting more complicated to get old devices to continue working.

TLS1.2 now required by default

https://docs.microsoft.com/en-us/microsoft-365/compliance/prepare-tls-1.2-in-office-365?view=o365-worldwide

My device is TLS 1.1 though, and i dont have a way to update the firmware to support TLS1.2 or TLS1.3

So Microsoft have a legacy TLS 1.1 endpoint endpoint which you can enable

https://techcommunity.microsoft.com/t5/exchange-team-blog/new-opt-in-endpoint-available-for-smtp-auth-clients-still/ba-p/2659652

Once enabled, you have to configured your devices to use smtp-legacy.office365.com

Microsoft is phasing out SMTP-AUTH in favour of OAUTH

SMTP-AUTH or basic auth is getting phased out. But similarly, devices dont support OAUTH yet.

So, you have to reenable SMTP-AUTH

https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online

https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/introducing-security-defaults/ba-p/1061414

You have to enable it in exchange in screen shot above, but ALSO you need to disable default security in azure.

Use app password since you have 2fa enabled

Finally since you have 2fa enabled, you will need to create an app password for you device to use.

I really like app77 Pwsafe, and was excited when i heard that Iphones would have NFC and Yubikey support.

I had hoped this would permit me to use my yubikeys with my iphone.

Their website said it was still not possible, but i was hoping that was just out of date. So, i emailed them.

http://pwsafe.info/yubikey/

They returned a very nice response, and thought folks would appreciate seeing it.

Hi Marty,

The NFC support of the iPhone is read only, meaning it can read a one-type password from the key. In this mode, the password/key pair can only be used as an authentication mechanism. If pwSafe would only authenticate you, we would have access to your data and would be gating access to it using your password and key to confirm your identify.

Instead, on pwSafe, the password is used to encrypt your data. This means the password cannot vary, otherwise the data would not decrypt correctly. To use the YubiKey, pwSafe on the Mac and Password Safe on Windows send the password gathered from the user to the key and then the YubiKey cryptographically combines it securely with another password stored inside the key itself that cannot be extracted. This is much more secure, because it means we can’t see your data or even comply to a court order telling us to disclose it. Your data remains encrypted and only you can read it, because decryption is only done in-device.

Long story short, pwSafe needs read/write support via NFC to be able to use the YubiKey. I hope this eventually comes to iOS. iOS 12, so far, doesn’t have it.

Best regards,

Solon B.
App77.com

I recently acquired a Garmin Fenix 5. In general, its a lovely device.

However, i found noticed the notifications were coming through to my phone very intermittently.

I enabled notifications on the watch, so that it vibrates and notifies when it looses bluetooth connectivity to the phone.

What i discovered, was it was connecting for around a minute, then disconnecting for a minute over and over and over.

The iphone bluetooth connectivity confirmed a similar thing.

I wrote to Garmin about it, and their response was

Dear Martin,

The issue you are referring to is something that we are aware of and are working hard towards a resolution, however, we do not have a timeframe for this to be completed as yet.

I have added you to the following case so that you will be notified once this issue has been resolved.

Case #: 1394354

I’m sorry for the inconvenience.

Kind regards,

Andrew

Garmin Europe

I cant find any mention of this case on the internet or in the Garmin forums.

However, the Garmin forums also are very broken now, which could be a reason.

Anyway, i post this here. Perhaps other people who have been given same case or issue can group together.

There were reports on the Garmin forums of the issue starting with IOS11. However, i never had the watch at this time, so i can’t confirm if that was a trigger.

I suspect i will give Garmin a month for more info, or i will return it.

Fenix 5 @ 6.00
Iphone 6 11.1.2

UPDATE 1. 2017-11-29. Received new email

Dear Martin,

First of all, please accept our apologies for not answering your email in the time we quoted on our website. Due to an unforeseeable high volume of emails and calls we’ve received this has led to a backlog, which we’ve been working hard to restore to our usual service levels.

Thank you for your query, I have provided answers for yourself below.

Regarding your first query please use this link below with information on the investigation and issue:

iOS 11 Bluetooth Connection Issues With Garmin Wearable Devices

I hope this should also answer your second query, all information can be found at the above FAQ link.

I completely understand what you are saying, sadly we do not currently have a time frame available for you. Although I can assure you that this is being looked into as we speak, please use the case reference provided by Andrew previously if you require an update. Once the issue is resolved we will notify you via email. As a workaround for now I would strongly recommend connecting the device to your computer to sync.

The recent update to ubuntu 17.04 broke everything about my setup, so i had to spend a lot of time understanding what changed so i could fix it.

pam-krb5 uses by default a slightly different path to the default for its credential cache.

/tmp/krb5cc_UID_RANDOM where UID is the user's UID and RANDOM is six randomly-chosen letters

cifs-utils has a helper function called cifs.upcall. It has had many changes over the last year. Notably 6.6 changed the way that correct credential caches was found.

Prior to 6.5, it would search for all cache files in /tmp/krb5cc* and see if the owner matched the requestor.

We can see this behaviour here:

Apr  9 17:33:09 rif cifs.upcall: key description: cifs.spnego;0;0;39010000;ver=0x2;host=server;ip4=192.168.50.2;sec=krb5;uid=0x0;creduid=0x44c;user=root;pid=0x8bb
Apr  9 17:33:09 rif cifs.upcall: ver=2
Apr  9 17:33:09 rif cifs.upcall: host=server
Apr  9 17:33:09 rif cifs.upcall: ip=192.168.50.2
Apr  9 17:33:09 rif cifs.upcall: sec=1
Apr  9 17:33:09 rif cifs.upcall: uid=0
Apr  9 17:33:09 rif cifs.upcall: creduid=1100
Apr  9 17:33:09 rif cifs.upcall: user=root
Apr  9 17:33:09 rif cifs.upcall: pid=2235
Apr  9 17:33:09 rif cifs.upcall: find_krb5_cc: considering /tmp/krb5cc_1100_drGvxJ
Apr  9 17:33:09 rif cifs.upcall: find_krb5_cc: FILE:/tmp/krb5cc_1100_drGvxJ is not a valid credcache.
Apr  9 17:33:09 rif cifs.upcall: find_krb5_cc: considering /tmp/krb5cc_0
Apr  9 17:33:09 rif cifs.upcall: find_krb5_cc: FILE:/tmp/krb5cc_0 is valid ccache
Apr  9 17:33:09 rif cifs.upcall: handle_krb5_mech: getting service ticket for grunt.variar.net
Apr  9 17:33:09 rif cifs.upcall: handle_krb5_mech: obtained service ticket
Apr  9 17:33:09 rif cifs.upcall: Exit status 0

After 6.6 it requires that the credential cache location be hard coded in the krb5.conf file.

6.7 additionally had an extra feature whereby it could find the KRB5CCNAME environment variable from the other session.

Once its working it should look something like:

Apr 17 22:27:38 rif cifs.upcall: key description: cifs.spnego;0;0;39010000;ver=0x2;host=server;ip4=192.168.50.2;sec=krb5;ui
d=0x44c;creduid=0x44c;user=root;pid=0x3584
Apr 17 22:27:38 rif cifs.upcall: ver=2
Apr 17 22:27:38 rif cifs.upcall: host=server
Apr 17 22:27:38 rif cifs.upcall: ip=192.168.50.2
Apr 17 22:27:38 rif cifs.upcall: sec=1
Apr 17 22:27:38 rif cifs.upcall: uid=1100
Apr 17 22:27:38 rif cifs.upcall: creduid=1100
Apr 17 22:27:38 rif cifs.upcall: user=root
Apr 17 22:27:38 rif cifs.upcall: pid=13700
Apr 17 22:27:38 rif cifs.upcall: get_cachename_from_process_env: pathname=/proc/13700/environ
Apr 17 22:27:38 rif cifs.upcall: get_existing_cc: default ccache is FILE:/tmp/krb5cc_1100
Apr 17 22:27:38 rif cifs.upcall: handle_krb5_mech: getting service ticket for grunt.variar.net
Apr 17 22:27:38 rif cifs.upcall: handle_krb5_mech: obtained service ticket
Apr 17 22:27:38 rif cifs.upcall: Exit status 0

The trick to getting it working was in the krb5.conf. I have to configure both kerberos and pam-krb5 to use the same file. My end config looks like the following:

[libdefaults]
default_realm = MYREALM.NET
forwardable = true
proxiable = true
default_ccache_name = FILE:/tmp/krb5cc_%{euid}

[realms]
MYREALM.NET = {
kdc = kdc.myrealm.net
admin_server = kdc.myrealm.net
}

[appdefaults]
pam = {
ccache = FILE:/tmp/krb5cc_%u
}

Critical to the above working is the creduid. This variable tells mount and cifs.upcall on whose behalf should the operation be made.

So, when i login via pam, or manually do kinit, my credential cache is always in the same place:

klist
Ticket cache: FILE:/tmp/krb5cc_1100
Default principal: mbarlow@SERVER

Valid starting     Expires            Service principal
17/04/17 22:46:32  18/04/17 22:46:32  krbtgt/MYREALM.NET@MYREALM.NET

My autofs mount looks like the following:

/etc/auto.master.d/auto.server:
/mnt/automount /etc/auto.servermaps

With the actual maps looking like:

/etc/auto.servermaps:
photos -fstype=cifs,sec=krb5,cruid=$USER,uid=$USER ://server/share