|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Password for CurrentUser()Dear all,
I'm using MDW file in my application. After the user login, can I know the password of CurrentUser() ? Thanks. Regards Vensia You can't. Why do you need to know? If you describe what you want to do,
there is likely a way. -- Show quoteJoan Wild Microsoft Access MVP Vensia wrote: > Dear all, > > I'm using MDW file in my application. > After the user login, can I know the password of CurrentUser() ? > Thanks. > > Regards > Vensia Hi Joan,
Actually I have several users. If I use MDW file, a user can save a version of existing MDW file, and then using it to open the application. I want there is a double checking for login validation. Thanks. Vensia Show quote "Joan Wild" <jwild@nospamtyenet.com> wrote in message news:Oi8g27G7GHA.4996@TK2MSFTNGP03.phx.gbl... > You can't. Why do you need to know? If you describe what you want to do, > there is likely a way. > > -- > Joan Wild > Microsoft Access MVP > > Vensia wrote: > > Dear all, > > > > I'm using MDW file in my application. > > After the user login, can I know the password of CurrentUser() ? > > Thanks. > > > > Regards > > Vensia > > Why would it be a problem if they saved and used a different copy of the
MDW? -- Show quoteJoan Wild Microsoft Access MVP Vensia wrote: > Hi Joan, > > Actually I have several users. If I use MDW file, a user can save a > version of existing MDW file, and then using it to open the > application. I want there is a double checking for login validation. > Thanks. > > Vensia > > "Joan Wild" <jwild@nospamtyenet.com> wrote in message > news:Oi8g27G7GHA.4996@TK2MSFTNGP03.phx.gbl... >> You can't. Why do you need to know? If you describe what you want >> to do, there is likely a way. >> >> -- >> Joan Wild >> Microsoft Access MVP >> >> Vensia wrote: >>> Dear all, >>> >>> I'm using MDW file in my application. >>> After the user login, can I know the password of CurrentUser() ? >>> Thanks. >>> >>> Regards >>> Vensia Let say I have a mdw file called payroll.mdw
In payroll.mdw file, default user name is admin with password 12345 Then the IT staff saves this payroll.mdw file in his PC. Later, the HR manager change the password for Admin user. Then the IT staff still can open the application using his MDW file with default user name and password. That's the problem. Thanks. Vensia Show quote "Joan Wild" <jwild@nospamtyenet.com> wrote in message news:#slF9VJ7GHA.2384@TK2MSFTNGP04.phx.gbl... > Why would it be a problem if they saved and used a different copy of the > MDW? > > > -- > Joan Wild > Microsoft Access MVP > > Vensia wrote: > > Hi Joan, > > > > Actually I have several users. If I use MDW file, a user can save a > > version of existing MDW file, and then using it to open the > > application. I want there is a double checking for login validation. > > Thanks. > > > > Vensia > > > > "Joan Wild" <jwild@nospamtyenet.com> wrote in message > > news:Oi8g27G7GHA.4996@TK2MSFTNGP03.phx.gbl... > >> You can't. Why do you need to know? If you describe what you want > >> to do, there is likely a way. > >> > >> -- > >> Joan Wild > >> Microsoft Access MVP > >> > >> Vensia wrote: > >>> Dear all, > >>> > >>> I'm using MDW file in my application. > >>> After the user login, can I know the password of CurrentUser() ? > >>> Thanks. > >>> > >>> Regards > >>> Vensia > > The Admin user shouldn't have any permission to do anything anyway, so it
shouldn't matter. I would give the HR manager and the IT staff different usernames; they can each change their own password all they want. I can see a scenario where it may be a problem: 1. you manage permissions by group. 2. a person is a member of Full Permissions group 3. that person takes a copy of the mdw 4. that person is later demoted and taken out of the Full Permissions group and put into Read Only 5. since they have an earlier copy of the mdw, and are using that, they can still get in as Full Permissions member. The workaround to that is to manage permissions by user, not group. That takes more work, but would prevent someone from getting around the security using the mdw (since permissions are stored in the mdb). You cannot retrieve the password of the CurrentUser (you can check that it isn't null, and you can reset it to null) -- Show quoteJoan Wild Microsoft Access MVP Vensia wrote: > Let say I have a mdw file called payroll.mdw > In payroll.mdw file, default user name is admin with password 12345 > Then the IT staff saves this payroll.mdw file in his PC. > Later, the HR manager change the password for Admin user. > Then the IT staff still can open the application using his MDW file > with default user name and password. > That's the problem. > Thanks. > > Vensia > > > > "Joan Wild" <jwild@nospamtyenet.com> wrote in message > news:#slF9VJ7GHA.2384@TK2MSFTNGP04.phx.gbl... >> Why would it be a problem if they saved and used a different copy of >> the MDW? >> >> >> -- >> Joan Wild >> Microsoft Access MVP >> >> Vensia wrote: >>> Hi Joan, >>> >>> Actually I have several users. If I use MDW file, a user can save a >>> version of existing MDW file, and then using it to open the >>> application. I want there is a double checking for login validation. >>> Thanks. >>> >>> Vensia >>> >>> "Joan Wild" <jwild@nospamtyenet.com> wrote in message >>> news:Oi8g27G7GHA.4996@TK2MSFTNGP03.phx.gbl... >>>> You can't. Why do you need to know? If you describe what you want >>>> to do, there is likely a way. >>>> >>>> -- >>>> Joan Wild >>>> Microsoft Access MVP >>>> >>>> Vensia wrote: >>>>> Dear all, >>>>> >>>>> I'm using MDW file in my application. >>>>> After the user login, can I know the password of CurrentUser() ? >>>>> Thanks. >>>>> >>>>> Regards >>>>> Vensia According to you, what is the best security approach for payroll software
product ? Each time the software is intalled, there is a default user name and password. If there are 2 installations (2 company) in the same office, I want to the user can not use his mdw to open the other company's data. Thanks. Vensia Show quote "Joan Wild" <jwild@nospamtyenet.com> wrote in message news:OE6#$aV7GHA.568@TK2MSFTNGP05.phx.gbl... > The Admin user shouldn't have any permission to do anything anyway, so it > shouldn't matter. > > I would give the HR manager and the IT staff different usernames; they can > each change their own password all they want. > > I can see a scenario where it may be a problem: > > 1. you manage permissions by group. > 2. a person is a member of Full Permissions group > 3. that person takes a copy of the mdw > 4. that person is later demoted and taken out of the Full Permissions group > and put into Read Only > 5. since they have an earlier copy of the mdw, and are using that, they can > still get in as Full Permissions member. > > The workaround to that is to manage permissions by user, not group. That > takes more work, but would prevent someone from getting around the security > using the mdw (since permissions are stored in the mdb). > > You cannot retrieve the password of the CurrentUser (you can check that it > isn't null, and you can reset it to null) > > > -- > Joan Wild > Microsoft Access MVP > > Vensia wrote: > > Let say I have a mdw file called payroll.mdw > > In payroll.mdw file, default user name is admin with password 12345 > > Then the IT staff saves this payroll.mdw file in his PC. > > Later, the HR manager change the password for Admin user. > > Then the IT staff still can open the application using his MDW file > > with default user name and password. > > That's the problem. > > Thanks. > > > > Vensia > > > > > > > > "Joan Wild" <jwild@nospamtyenet.com> wrote in message > > news:#slF9VJ7GHA.2384@TK2MSFTNGP04.phx.gbl... > >> Why would it be a problem if they saved and used a different copy of > >> the MDW? > >> > >> > >> -- > >> Joan Wild > >> Microsoft Access MVP > >> > >> Vensia wrote: > >>> Hi Joan, > >>> > >>> Actually I have several users. If I use MDW file, a user can save a > >>> version of existing MDW file, and then using it to open the > >>> application. I want there is a double checking for login validation. > >>> Thanks. > >>> > >>> Vensia > >>> > >>> "Joan Wild" <jwild@nospamtyenet.com> wrote in message > >>> news:Oi8g27G7GHA.4996@TK2MSFTNGP03.phx.gbl... > >>>> You can't. Why do you need to know? If you describe what you want > >>>> to do, there is likely a way. > >>>> > >>>> -- > >>>> Joan Wild > >>>> Microsoft Access MVP > >>>> > >>>> Vensia wrote: > >>>>> Dear all, > >>>>> > >>>>> I'm using MDW file in my application. > >>>>> After the user login, can I know the password of CurrentUser() ? > >>>>> Thanks. > >>>>> > >>>>> Regards > >>>>> Vensia > > Vensia wrote:
> According to you, what is the best security approach for payroll Not sure what you mean by this? When access first presents the login > software product ? > Each time the software is intalled, there is a default user name and > password. dialog, it will fill in the username with the Windows logon name, and the password will be blank. The username can be changed to whatever it needs to be. The next time the login dialog is shown, it'll show the username of the last person who used it. > If there are 2 installations (2 company) in the same office, I want I would create separate groups for the 2 companies. Make sure that said > to the user can not use his mdw to open the other company's data. > Thanks. user isn't a member of company two's group. -- Joan Wild Microsoft Access MVP I mean this is a mass product. So there is already a user with name : admin
and password : 123. Anyone who buy the product will have the same user name and password for the first time login. What is your suggestion for the good security ? Thanks. Show quote "Joan Wild" <jwild@nospamtyenet.com> wrote in message news:uAzo2cf7GHA.5020@TK2MSFTNGP03.phx.gbl... > > Vensia wrote: > > According to you, what is the best security approach for payroll > > software product ? > > Each time the software is intalled, there is a default user name and > > password. > > Not sure what you mean by this? When access first presents the login > dialog, it will fill in the username with the Windows logon name, and the > password will be blank. The username can be changed to whatever it needs to > be. The next time the login dialog is shown, it'll show the username of the > last person who used it. > > > If there are 2 installations (2 company) in the same office, I want > > to the user can not use his mdw to open the other company's data. > > Thanks. > > > I would create separate groups for the 2 companies. Make sure that said > user isn't a member of company two's group. > > -- > Joan Wild > Microsoft Access MVP > > Vensia wrote:
> I mean this is a mass product. So there is already a user with name : The user "Admin" is the same in all workgroup files, but it only has that > admin and password : 123. > Anyone who buy the product will have the same user name and password > for the first time login. > What is your suggestion for the good security ? > Thanks. password in YOUR workgroup. If you are allowing that user to open the file then you are letting anyone open the file as long as they use a workgroup that has no password on the Admin user or one where they know the password for the Admin user. The most basic rule of Access security is that the default user Admin and the default group Users must have zero permissions and zero ownership. -- Rick Brandt, Microsoft Access MVP Email (as appropriate) to... RBrandt at Hunter dot com > I mean this is a mass product. There's a significant problem with changing passwords on "mass products". Ifyou use PDW to distribute, there is NO provision for network setups. This means, by default, I have a copy of the mdw in each local folder. To fix it, requires "shifting" mdw to the network folder, perhaps by a long telephone conversation. Very long! I don't worry too much about it, because "most" sites don't worry about changing passwords, but if they do they have to shift it (the mdw)(let alone old backups). There is no workaround (no reasonable network mdw install) in PDW. Other installers like Sagekey or Installer2Go may or may not have. Whatever I did, on a "mass product" they could always restore the original CD mdw, which in my case has no passwords! (except for the assignated "DBA", but even then it is standard across all sites) Why am I fighting a losing battle with Access Security? <grin> Chris Just to get my understanding right (not yours), any given perms on a table are
contained within the live MDB, right? There is only one usefull copy of them. She (or Vensia) was talking about passwords,which are contained in the mdw, something which doesn't change that often, and might well have old useable copies lying about? Managing by User not Group is an interesting idea (against the normal advice), but if I read things right this might not achieve much? The User might still be in an old mdw, making that pointless? She (or, it!) referred only to changing passwords? I also think they (or, she!) are getting beyond the capacity of Access Security. Certainly, you could restore a backup of mine (where I changed passwords) and use the older ones! Chris Show quote "Joan Wild" <jwild@nospamtyenet.com> wrote in message news:OE6%23$aV7GHA.568@TK2MSFTNGP05.phx.gbl... > The Admin user shouldn't have any permission to do anything anyway, so it > shouldn't matter. > > I would give the HR manager and the IT staff different usernames; they can > each change their own password all they want. > > I can see a scenario where it may be a problem: > > 1. you manage permissions by group. > 2. a person is a member of Full Permissions group > 3. that person takes a copy of the mdw > 4. that person is later demoted and taken out of the Full Permissions group > and put into Read Only > 5. since they have an earlier copy of the mdw, and are using that, they can > still get in as Full Permissions member. > > The workaround to that is to manage permissions by user, not group. That > takes more work, but would prevent someone from getting around the security > using the mdw (since permissions are stored in the mdb). > > You cannot retrieve the password of the CurrentUser (you can check that it > isn't null, and you can reset it to null) > > > -- > Joan Wild > Microsoft Access MVP > > Vensia wrote: > > Let say I have a mdw file called payroll.mdw > > In payroll.mdw file, default user name is admin with password 12345 > > Then the IT staff saves this payroll.mdw file in his PC. > > Later, the HR manager change the password for Admin user. > > Then the IT staff still can open the application using his MDW file > > with default user name and password. > > That's the problem. > > Thanks. > > > > Vensia > > > > > > > > "Joan Wild" <jwild@nospamtyenet.com> wrote in message > > news:#slF9VJ7GHA.2384@TK2MSFTNGP04.phx.gbl... > >> Why would it be a problem if they saved and used a different copy of > >> the MDW? > >> > >> > >> -- > >> Joan Wild > >> Microsoft Access MVP > >> > >> Vensia wrote: > >>> Hi Joan, > >>> > >>> Actually I have several users. If I use MDW file, a user can save a > >>> version of existing MDW file, and then using it to open the > >>> application. I want there is a double checking for login validation. > >>> Thanks. > >>> > >>> Vensia > >>> > >>> "Joan Wild" <jwild@nospamtyenet.com> wrote in message > >>> news:Oi8g27G7GHA.4996@TK2MSFTNGP03.phx.gbl... > >>>> You can't. Why do you need to know? If you describe what you want > >>>> to do, there is likely a way. > >>>> > >>>> -- > >>>> Joan Wild > >>>> Microsoft Access MVP > >>>> > >>>> Vensia wrote: > >>>>> Dear all, > >>>>> > >>>>> I'm using MDW file in my application. > >>>>> After the user login, can I know the password of CurrentUser() ? > >>>>> Thanks. > >>>>> > >>>>> Regards > >>>>> Vensia > > Chris Mills wrote:
> Just to get my understanding right (not yours), any given perms on a Exactly.> table are contained within the live MDB, right? There is only one > usefull copy of them. > Managing by User not Group is an interesting idea (against the normal But why is that pointless? Once logged in as that user (regardless of what > advice), but if I read things right this might not achieve much? The > User might still be in an old mdw, making that pointless? mdw they use), they are still restricted by the permissions that are applied to that username, which is stored in the mdb. -- Joan Wild > > User might still be in an old mdw, making that pointless? I read Vensia, in the payroll example, as a customer altering their password,> > But why is that pointless? and of course the old password can be re-implemented with a restored mdw. If that is her issue, I agree it is true! I don't know of a way to protect from restoring old backups -unless one did some sort of re-securing, which is not usually (there I go again!) contemplated after deployment. I could always have mis-read Vensia :-) I didn't really worry about things like potential old password restoral (you can't worry TOO much about securing Access can you!) Whilst I want my PROGRAM reasonably protected from copying, if a client has IT smart-alecs I'd be inclined to give-up. More accurately, other security like restricted physical access to the Accountant's machine. I think it's fair to say that site security cannot solely be what Access provides? (employees have to sign non-disclosure agreements, are liable to prosecution, locked open-plan offices <guffaw>, but certainly not solely Access) Just to clarify, my s/w (a CD distributed to xxx sites), of course has the same passwords for each. The Developer password is known only to me <g>, the site DBA password is pre-set to some published value which the site DBA can change, and all the users are initially set to blank passwords (or a published password who cares) which they can change if they want. And if they change passwords, they can always restore the original ones from the distribution CD! This is specific to bulk-distributing the same CD. It might be very different if you can personally customise each site. The program-copying security is other things (like, dare I say it, dongles or HD serial numbers) I do not realistically protect the client from their own data (using Access). Call me a b'tard, but I'm only interested in my prog being ripped off! I CANT protect them from their data (?) BTW, in a "closed vertical market" other security can come into effect, such as eventually some rip-off site will forget and call the published phone number for service! It's true, it has happened to me! It helps if your prog is badly written so that it needs service <g> Chris Chris Mills wrote:
>>> User might still be in an old mdw, making that pointless? But my point was that instead of applying permissions to groups, you can >> >> But why is that pointless? > > I read Vensia, in the payroll example, as a customer altering their > password, and of course the old password can be re-implemented with a > restored mdw. > > If that is her issue, I agree it is true! I don't know of a way to > protect from restoring old backups -unless one did some sort of > re-securing, which is not usually (there I go again!) contemplated > after deployment. apply them to users. Even if a user restores an old mdw and uses their old password, they won't get the permissions they had with that old password, they'll get the permissions applied to that username, which are stored in the mdb. -- Joan Wild I don't follow you at all/
A user can change their password. Perms don't alter just for this change. Old password can be restored with old mdw. (just another way of changing the password back) Doesn't matter if perms are on users or groups, or so my tests indicate. They are not affected by change of password (as against PID say) (a client would do no more than change their password, on a bulk product anyway. That's a minor mdw change only, however perms are set up). But perhaps let Vensia come back with something. I always fear I misunderstood something :-) Chris We are talking about different things. I put forward the scenario where you
manage security by groups. A user takes a copy of the mdw in which they are a member of the supergroup. In the original group, they are removed from supergroup and put in the peon group. If they use their copy of the mdw, they can over-ride the change to the peon group. In their mdw they are still a member of supergroup, so by using that mdw they will have permissions they shouldn't. A workaround is to manage permissions by user instead of by group. It has nothing to do with password changes. -- Show quoteJoan Wild Microsoft Access MVP Chris Mills wrote: > I don't follow you at all/ > > A user can change their password. Perms don't alter just for this > change. > > Old password can be restored with old mdw. (just another way of > changing the password back) > > Doesn't matter if perms are on users or groups, or so my tests > indicate. They are not affected by change of password (as against PID > say) > > (a client would do no more than change their password, on a bulk > product anyway. That's a minor mdw change only, however perms are set > up). > > But perhaps let Vensia come back with something. I always fear I > misunderstood something :-) > > Chris Are "peon"s inhabitants of Venus?
(sorry - no meaning!) Well, I see that, if structural changes have taken place (regarding changing groups around as structural). But hopefully <g> on a "mass product", such things were stabilised during development. With the best ULS setup in the world (which I always do of course <cough>), of course (mass product) Company1 and Company2 have the same initial passwords. Which can be reverted to at any time or by any means. Vensia, Without tailoring the mdw or ULS each time, of course Company2 could potentially access Company1 data. If it's the identical bulk "setup", there's no difference whatever between a Company2 machine or another machine installed at Company1. Rick referred to not using "admin", if you meant that username literally, because it's a default "superuser" for all Access. I am assuming your ULS security is setup "perfectly"/your issue seems still true. Because "bulk product" means IDENTICAL (at installation), yes one of my clients using the same product can get into another client's data, if they had physical access and a copy of the original mdw. I simply regard that as obvious/nothing I can do much about (apart from tailoring each site). Alternative viewpoint is: you (as developer) or me (with 1/10 of Joan's knowledge) could no doubt get into it too - so anyone with an average or so knowledge of Access security can! For the same reason, I distribute standard logons like User1 to Userxxx (mappable to actual names within the program), because the user can't modify security beyond changing passwords. Is there a better (and secure)way to let users setup logons? (I have a specific interest in new suggestions here! :-) ) Chris Jumping in halfway in reviewing this thread, yes it's true that saving a copy
of an mdw saves "old" passwords. I usually look at it the other way, that multiple copies of an mdw mean if you change one password, you may not have changed all copies of it! (due to limitations of PDW installs, I often have multiple copies of an mdw, accepting that it's naughty if I want to change passwords etc). Anyhow, yes that's a danger (old files/old passwords). Whatever you do, you couldn't prevent (for instance) someone recovering an old backup mdw! (unless someone else knows how) I think Access Security is quite good, so far as it goes. But consider the possibility that you are trying to ascribe to Access more security than is there! (some claim, with reason, that it is not secure at all, which I think is slightly exaggerated/only true of Access Experts) You are talking about a File Management problem, which at least requires an On-Site Administrator with integrity. As such, it is nothing to do with "Access Security" per se, and you already understand the issue by posting it. There's a thousand ways in which Access security can be broken (I am told!), of which you have identified just one. I have heard that it's recoverable even without the mdw. It is often said, that if you want beyond a certain level of security, then you might like to consider SQLserver or some-such. As has been mentioned, you wouldn't have a logon of Admin (or any one of the Access default users or groups), but something else like YourDBA. I think the SecFAQ covers this adequately. But it doesn't cover old copies because no-one can? I think Access Security works fine for the average Office Secretary and CEO (!!!) Also by my reading, it all becomes irrelevant from A2007 (except for legacy-mode). Not Security becomes irrelevant, but ULS does. If you are contemplating using the latest Access, it seems to me you would need to discard all current concepts. (I'm not myself interested in latest Access) Chris Show quote "Vensia" <vensia2000_nospam@yahoo.com> wrote in message news:eNyoJ3N7GHA.4580@TK2MSFTNGP03.phx.gbl... > Let say I have a mdw file called payroll.mdw > In payroll.mdw file, default user name is admin with password 12345 > Then the IT staff saves this payroll.mdw file in his PC. > Later, the HR manager change the password for Admin user. > Then the IT staff still can open the application using his MDW file with > default user name and password. > That's the problem. > Thanks. > > Vensia > > > > "Joan Wild" <jwild@nospamtyenet.com> wrote in message > news:#slF9VJ7GHA.2384@TK2MSFTNGP04.phx.gbl... > > Why would it be a problem if they saved and used a different copy of the > > MDW? > > > > > > -- > > Joan Wild > > Microsoft Access MVP > > > > Vensia wrote: > > > Hi Joan, > > > > > > Actually I have several users. If I use MDW file, a user can save a > > > version of existing MDW file, and then using it to open the > > > application. I want there is a double checking for login validation. > > > Thanks. > > > > > > Vensia > > > > > > "Joan Wild" <jwild@nospamtyenet.com> wrote in message > > > news:Oi8g27G7GHA.4996@TK2MSFTNGP03.phx.gbl... > > >> You can't. Why do you need to know? If you describe what you want > > >> to do, there is likely a way. > > >> > > >> -- > > >> Joan Wild > > >> Microsoft Access MVP > > >> > > >> Vensia wrote: > > >>> Dear all, > > >>> > > >>> I'm using MDW file in my application. > > >>> After the user login, can I know the password of CurrentUser() ? > > >>> Thanks. > > >>> > > >>> Regards > > >>> Vensia > > > > > > Hi
Probably this helps: System.Web.Security.ActiveDirectoryMembershipProvider.GetPassword(ByVal username As String, ByVal passwordAnswer As String) As String Bye Show quote "Vensia" <vensia2000_nospam@yahoo.com> wrote in message news:e$6%23f6D7GHA.1560@TK2MSFTNGP04.phx.gbl... > Dear all, > > I'm using MDW file in my application. > After the user login, can I know the password of CurrentUser() ? > Thanks. > > Regards > Vensia > > This could help, too
: http://www.vbdotnetheaven.com/UploadFile/ankithakur/Login_Using_Active_Directory08012006061813AM/Login_Using_Active_Directory.aspxBye Nip Show quote "Nip" <lu***@quantentunnel.de> wrote in message news:ORMmqsFAHHA.4328@TK2MSFTNGP03.phx.gbl... > Hi > > Probably this helps: > System.Web.Security.ActiveDirectoryMembershipProvider.GetPassword(ByVal > username As String, ByVal passwordAnswer As String) As String > > Bye > > "Vensia" <vensia2000_nospam@yahoo.com> wrote in message > news:e$6%23f6D7GHA.1560@TK2MSFTNGP04.phx.gbl... >> Dear all, >> >> I'm using MDW file in my application. >> After the user login, can I know the password of CurrentUser() ? >> Thanks. >> >> Regards >> Vensia >> >> > 1) There's no connection between CurrentUser in Access and whatever has been
defined in ActiveDirectory. 2) Your code samples are .Net, whereas Access uses VBA. -- Show quoteDoug Steele, Microsoft Access MVP http://I.Am/DougSteele (no private e-mails, please) "Nip" <lu***@quantentunnel.de> wrote in message news:ORMmqsFAHHA.4328@TK2MSFTNGP03.phx.gbl... > Hi > > Probably this helps: > System.Web.Security.ActiveDirectoryMembershipProvider.GetPassword(ByVal > username As String, ByVal passwordAnswer As String) As String > > Bye > > "Vensia" <vensia2000_nospam@yahoo.com> wrote in message > news:e$6%23f6D7GHA.1560@TK2MSFTNGP04.phx.gbl... >> Dear all, >> >> I'm using MDW file in my application. >> After the user login, can I know the password of CurrentUser() ? >> Thanks. >> >> Regards >> Vensia >> >> > "Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in 3) There is no way in any security system to retrieve the passwordnews:#zdjqGNAHHA.4672@TK2MSFTNGP02.phx.gbl: > 1) There's no connection between CurrentUser in Access and > whatever has been defined in ActiveDirectory. > > 2) Your code samples are .Net, whereas Access uses VBA. from a user account. If there were, they wouldn't be "security systems". "David W. Fenton" <XXXuse***@dfenton.com.invalid> wrote in message I didn't think it was necessary to point out the obvious. <g>news:Xns9872A0701BA81f99a49ed1d0c49c5bbb2@127.0.0.1... > "Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in > news:#zdjqGNAHHA.4672@TK2MSFTNGP02.phx.gbl: > >> 1) There's no connection between CurrentUser in Access and >> whatever has been defined in ActiveDirectory. >> >> 2) Your code samples are .Net, whereas Access uses VBA. > > 3) There is no way in any security system to retrieve the password > from a user account. If there were, they wouldn't be "security > systems". -- Doug Steele, Microsoft Access MVP http://I.Am/DougSteele (no private e-mails, please) Hi NG
Sorry, I just had read some network stuff in another group and was programming .net besides it, so I mixed things up. Bye Nip Show quote "Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in message news:O7%23ZFLSAHHA.3836@TK2MSFTNGP02.phx.gbl... > "David W. Fenton" <XXXuse***@dfenton.com.invalid> wrote in message > news:Xns9872A0701BA81f99a49ed1d0c49c5bbb2@127.0.0.1... >> "Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in >> news:#zdjqGNAHHA.4672@TK2MSFTNGP02.phx.gbl: >> >>> 1) There's no connection between CurrentUser in Access and >>> whatever has been defined in ActiveDirectory. >>> >>> 2) Your code samples are .Net, whereas Access uses VBA. >> >> 3) There is no way in any security system to retrieve the password >> from a user account. If there were, they wouldn't be "security >> systems". > > I didn't think it was necessary to point out the obvious. <g> > > -- > Doug Steele, Microsoft Access MVP > http://I.Am/DougSteele > (no private e-mails, please) > >  |
|||||||||||||||||||||||
Other interesting topics