Our UPN and primary SMTP are different and since the parent company controls that aspect of the environment I cannot change that.
UPN: name#parentcorp.com
Email: name#childcorp.com
I have an on-prem ADFS 4.0 server which we have complete control over and so far we have about 12 website/apps setup which all work fine.
In every instance so far the website has a field for "email" and a separate field I can use for "federation ID" which I populate w/ the UPN.
Then I setup my claims to accept the UPN as NameID and everything is normal.
Now I have to setup two new sites which don't give me that option however I have to put in the Primary SMTP into the email field and that is the only field I can pass to my claim.
I'm wondering if it's possible for our users to still sign in using name#parentcorp.com even though the email is name#childcorp.com.
Normally I would think this would be possible but I read an MS article about configuring an alternate logon ID and thought that might be possible. Or using the Transform Incoming Claim option under the Claim Policy section.
Both are possible but they are different use cases. One is authentication; one is claims.
You can use any AD field for AlternateID.
And yes, you can use a Transform claim.
Need more detail as the exact requirement.
Related
client has 2 different domains (due to acquisition) in one M365 tenant and wants to make sure they don't see each other in contacts using Address Book Policies. I have been able to do my best to separate them by using Company field however I am stuck with how to handle their Mail-Enabled Security Groups.
I made an address list called "Client1AddressList" and set the -IncludedRecipients to "MailGroups" which is great and brings every group in, however it doesn't care about the domain whether it is allstaff#client1.com or allstaff#client2.com.
I thought maybe adding on a -RecipientFilter to the end of the Set-AddressList would help, but I cant figure out what that filter would look like to tell it to only add groups that have an email of *#client1.com
Thank you any geniuses out there that can lend a hand!
Our old authentication mechanism had mandatory and immutable email for each user by design. After exporting old authentincation mechanism into the hands of Keycloak 4.6.Final, We are left with old references to users by email as this was in fact used as an id from the beginning of this system.
Keycloak User Management UI is delivered to client as part of a whole system. Now we're facing a problem where the users administrator at the customer's side is able to create users with no email, and even worst, he give a user one email and overtime change it. Leaving this option open is most likely to create bugs for the client as the user base grows.
I've been digging around google, sof, keycloak mailing list search engine, and couldn't find any documentation relating developer's ability to apply configuration on top of particular keycloak distribution which would set features such as mandatory and immutable on some user attributes which are optional and editable by default.
I know that question is old, but maybe someone will need answer.
it's 2022-11 and there is experimentas feature in Keycloak 20. You can enable declarative-user-profile and then customize your user profile and set required fields and other options. user-profile
This feature may be removed in the future, because it's experimental.
And this feature has bugs (tried with 20.0.1). For example, if you add required attribute group, then you can see groups while creating new user and you can select groups. But if you try to save user, then error appears telling, that group is required.
I have signed up earlier for the google apps account which is now called as legacy and the primary domain has got expired. I am trying to bootstrap a startup ourselves and thought of using this legacy account. below are the steps I tried so see if I can change the primary domain. let me know if anyone of you know about any existing solutions.
No option to add a secondary domain because its a legacy account. Google removed the option.
Added our new domain as a domain alias.
Went through the GAM tool, Admin SDK.
There are couple of options which I could think off to achieve this.
Upgrade the google legacy account to a 30 day trial account and get the option to add a secondary domain and then make the primary domain change and downgrade. However, from what I have read in the internet, there is a risk where when I downgrade there would be only 1 license to use.
https://www.isaumya.com/how-to-change-primary-domain-for-google-apps-legacy-account/ here is a website telling me they have a script to run and make these changes and asking for 30 dollars.
https://github.com/marcelobern/Google-Admin-SDK-Domain This is another option that I came across.
I know it a sounds a bit crude but I am just trying to use a freebie till we get a funding for the startup :) Let me know if anyone of you have any solutions.
If you do the free trial, you will gain the ability to add a domain rather than a domain alias. However, you will not be able to downgrade back to legacy free until you remove the domain. (I tried this on an account I was willing to lose).
For your purposes I think you could get away with using the domain alias. Your users will need to sign in under the old primary domain name but your users can configure your domain alias as the default outgoing email address under settings/Accounts/Send mail as.
I need to know if an installation has been paid for in the past so I can provide some premium features.
Storing a payment flag in indexeddb or the file system sounds easy to defeat. Periodically asking a server and caching the response could do the trick, but I guess the user would have to be logged-in at all times (through google or otherwise) and I'd rather not impose that restriction.
Maybe if there's a way to uniquely identify a user's machine (uuid, mac address, etc) that could allow me to determine if they've made that payment?
Ultimately, this is client side JavaScript. The only means by which you can prevent use of certain features, is to put them on your server and charge for the service.
Some weak methods for preventing access include license validation, and asking the server for non-essential information (if it was essential, then see the above).
For license validation, you could create an algorithm that takes data from the user and transforms it into something else. For example, say they create an account on your website, which your server knows is a 'pro' account. You could then take their first name and email address and do some magic on it.
Here's a simple example that takes those inputs and gives us a key. In this example if our first name is "John" and our email is "john#domain.org", then our key will be fcumnflqjpBfqockp0qtifcufLqjp. However, Tony, with the email "tony#doman.org" would recieve fcumnfvqp{Bfqockp0qtifcufVqp{
You can send this key to the user, and have your code decide whether it can extract the name and email by applying the reverse algorithm.
You can reverse the strings, do various bit math, etc. It's security by obscurity. Other than an account, this is the most common method. It's used by nearly all offline software. Its kryptonite is key generators, which reverse engineer your code, and generate keys by the algorithm you use to verify them.
All the methods such as uuid, mac address etc can be easily forged imo. I think you cannot escape keeping track of user's logged-in status. Implementing something like a cookie based mechanism would be the right way to go.
I'm about to start building a new asp.net project, and I'm just starting out with the whole thing of SQLMembershipProvider. What I really want to do is to remove the need for a username and just have the key to the user as the email address.
It seems to me that the easiest thing might be to change the stored procedures to just remove the email address from the tables, and when someone does a search by email, just to use the key (I also need to deal with someone changing their email address...
Before I start, does anyone know a pre-rolled example out there. It just seems too common to have to build it.
You don't need to change anything in the provider. Just set the email as user name upon registration and don't provide any means in the UI to change the email address. It'll do the work easily.
You could modify the procedures... or just omit the email or username fields in your forms/ui and use one or the other behind the scenes to populate the other field. This might be duplicate data, but you might find a need to have an email that isn't also the username down the road.