We’ve been getting the Autodesk sign-in wall on Flame 2027.1:
Unable to authorize license
Your system settings, firewall, or antivirus are likely preventing sign in.
It’s not the license server, and it’s not Boris/Neat. It’s Autodesk’s IDSDK / SSO stack that 2027.1 uses to authorize Flame.
What’s actually happening
Flame now keeps an encrypted identity DB (idservices.db) and puts the AES key in the user’s gnome-keyring. If that keyring isn’t there, isn’t unlocked, or is on a filesystem that doesn’t do POSIX locks the way Autodesk expects, sign-in dies and you get the firewall story.
Three things keep lining up for us:
NFS home directories. Identity state and keyrings on shared homes are a bad fit. Locks and host-bound encrypted DBs written on one box don’t behave on the next one, or after a remount.
PCoIP / Teradici sessions. GDM usually starts and unlocks gnome-keyring. A lot of PCoIP PAM stacks capture the password and never really do the session half, so you get a keyring with no secrets. After a reboot the DB is still on disk and the key is gone. Decrypt fails (we’ve been seeing error 3043).
Crash leftovers. If Flame or AdskIdentityManager dies, POSIX semaphores can sit in /dev/shm forever. Next launch hangs on the lock (error 3211). Same thing if you try to “help” by pre-starting Identity Manager — it races Flame’s licensing agent for the SSO mutex and you reproduce the failure.
There’s also a nasty footgun: a default → login pointer in ~/.local/share/keyrings with no login.keyring file. Identity Manager starts in NoUI (Did not find default collection) and PAM won’t create the missing file. Artist sees the same license modal.
What we stopped doing
Don’t start AdskIdentityManager for the user.
Don’t invent a gnome-keyring collection from SSH. That pops a password dialog on their PCoIP session and hangs.
Keep Autodesk identity state and the gnome-keyring on local disk, not NFS. Make sure PCoIP actually starts/unlocks gnome-keyring. After a crash, clear the leftover IDSDK locks in /dev/shm before the next launch. If the keyring is gone but idservices.db is still there, reset the identity DB and let them sign in once from the desktop.
After that, one clean Flame launch + Autodesk SSO and they’re in.
ADSK did something over the weekend. This is the 5th time I heard this problem today, and I lived through one myself.
In my case nuking /dev/shm/ for occurences of IDSK (with asterixis around it) solved it.
In total customer base impact and angry customers, ID services should have the brightest in the company working on this. But it seems they park the leftovers there instead.
Mind you, most of these reports are from ADSK certified configs, not random surprises.
None of the other software we regularly use has as many issues as ADSK by a mile and then some. The only other incident I remember from someone else was with Nuke a few years back.
Semi-emperical evidence, take it for what it’s worth.
I had ‘no license’ errors on my Mac the last week. Didn’t bother fixing and used another system.
This morning I went to the ADSK website, and downloaded/installed the latest version ‘Identity Manager 1.19.1’ and ‘Autodesk Licensing Service 16.5.0.16154’. Flame launched without issue after that.
Your mileage may vary. But while you’re waiting on support to get back to you, it’s worth a shot. There is reason to believe these are the troubled parts, and they run on their own update and patch cycle and are downloadable via the ‘Product Updates’ section.
I’ve done these updates a handful of times. They never made it worse.
Autodesk Flame 2027.1 is failing to sign in because its new SSO system relies on local gnome-keyring and encrypted files that break on shared network drives (NFS), fail to unlock during remote PCoIP sessions, or hang due to leftover lock files in /dev/shm after a crash.
Fix: Clear any leftover IDSDK locks inside /dev/shm and keep identity files on local disk storage rather than NFS.
had this happen to us the other day on 27.1